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内 容 提 要 
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比较 。 

本 书 适 合 中 高 级 Java 程序 员 和 软件 架构 师 阅 读 。 
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“这 本 书 深入 探讨 了 RxJava 的 理念 和 用 法 ， 以 及 反应 式 编程 的 通用 知识 。 两 位 作者 在 实现 
和 使 用 RxJava 方面 拥有 丰富 的 经 验 。 如 果 你 想 掌握 反应 式 编程 ， 那 么 没有 比 阅读 这 本 书 
更 好 的 方法 了 。” 












































Erik Meijer，Applied Duality 公司 总 裁 兼 创始 人 





“对 于 现代 Android 应 用 程序 来 讲 ， 高 度 状态 化 、 并 发 和 异步 实现 是 基本 的 特性 ， 而 RxJava 
是 管理 它们 的 好 工具 。 这 本 书 既是 一 个 渐进 式 的 学 习 工具 ， 也 是 一 份 随时 可 翻阅 的 参考 次 
料 ， 如 果 没 有 它 ， 掌 握 RxJava 这 个 库 可 能 会 非常 困难 。” 


Jake Wharton，Square 公司 软件 工程 师 


























“ 托 马 什 和 本 在 使 用 简单 的 方式 解释 复杂 的 事物 方面 很 有 天 赋 ， 这 就 是 这 本 书 读 起 来 很 令 
人 愉悦 的 原因 。 对 于 每 一 个 想 要 掌握 反应 式 编程 和 RxJava 的 JVM 开发 人 员 来 说 ， 这 本 书 
都 是 案头 书 。 作 者 谈 及 了 许多 主题 ， 如 并 发 、 函 数 式 编程 、 设 计 模 式 和 反应 式 编程 。 但 
是 ， 这 么 多 的 内 容 并 不 会 令 读 者 却步 ， 而 是 会 引领 读者 循序 渐进 地 掌握 越 来 越 高 级 的 概念 
和 技术 。 























Szymon Homa， 高 级 软件 工程 师 





译 者 序 


随 着 Spring 5 引入 对 反应 式 编程 的 支持 ， 反 应 式 编程 模式 在 Java 领域 中 也 得 到 了 前 所 未 有 
的 关注 。 其 实在 其 他 语言 中 ， 反 应 式 编程 的 理念 出 现 和 应 用 得 更 早 一 些 ， 比 如 Angular 很 
早 就 将 RxJS 纳入 HTTP 请 求 等 使 用 场景 了 。 


Java 静态 化 的 特点 ， 导 致 一 些 函 数 式 或 回调 式 的 编程 模式 很 难 便利 地 应 用 到 Java 程序 员 
日 常 的 开发 中 。 正 是 在 这 样 的 背景 下 ，RxJava、Reactor 等 反应 式 编程 框架 得 到 了 社区 和 
广大 开发 人 员 的 青睐 。RxJava 广泛 应 用 于 Android 应 用 程序 的 开发 ， 借 助 RxJava 开发 的 
Hystrix 更 是 成 为 了 现代 微服 务 应 用 程序 的 标准 配置 。 反 应 式 编程 的 特点 在 于 语法 简洁 、 运 
行 高 效 、 性 能 开销 可 控 ， 未 来 将 是 一 种 主流 的 开发 模式 。 

就 目前 来 看 ， 反 应 式 编程 在 企业 级 应 用 中 的 直接 应 用 还 比较 少 。 主 要 的 困难 有 两 个 : 一 个 
是 关系 数据 库 的 访问 ， 另 一 个 是 网 络 请 求 的 调用 。 这 在 很 大 程度 上 是 因为 JDBC 和 HTTP 
本 身 具 有 阻塞 式 的 特点 。 不 过 情况 正在 改变 : R2DBC 项 目 致力 于 将 反应 式 编程 API 应 用 
到 关系 型 数据 存储 中 ， 而 RSocket 项 目 则 致力 于 提供 一 个 符合 反应 式 流 语义 的 应 用 层 协议 。 
相信 随 着 这 些 项 目 在 技术 和 社区 方面 的 不 断 成 熟 ， 反 应 式 编程 在 开发 人 员 的 工具 箱 中 会 占 
据 越 来 越 重要 的 地 位 。 


本 书 全 面 阐述 了 反应 式 编程 的 理念 ， 以 及 这 些 理念 是 如 何在 RxJava 中 实现 的 。 尤 为 难 能 
可 贵 的 是 ， 除 了 从 头 构建 完整 的 反应 式 应 用 程序 之 外 ， 作 者 还 细致 前 述 了 如 何 向 已 有 的 应 
用 程序 逐步 引入 RxJava 框架 。 


稍微 美中不足 的 是 本 书 撰写 得 较 早 ， 是 基于 RxJava 1.x 版 本 的 。 虽 然 1x 版 本 非常 成 熟 ， 
而 且 得 到 了 广泛 的 应 用 ， 但 是 现在 的 2.x 版 本 是 基于 反应 式 流 规范 重新 编写 的 。 不 过 ， 从 
RxJava 1.x 到 RxJava 2.x， 核 心 的 设计 理念 是 一 脉 相 承 的 。 为 了 便于 读者 实现 从 RxJava 1.x 
到 RxJava 2.x 的 迁移 ， 经 允许， 我 翻译 了 RxJava 项 目 领导 者 Dévid Karnok 的 两 篇 关于 
RxJava 2.0 的 文章 ， 并 作为 本 书 的 附录 C， 供 读者 参考 。 除 此 之 外 ， 我 和 《反应 式 设计 模式 》 
一 书 的 译 者 何 品 分 又 (fork) 编写 了 本 书 的 源 代 码 ， 会 逐步 将 本 书 中 较为 独立 的 章节 的 源码 



















































































































































































Xiii 


升级 为 RxJava 2.0。 读 者 可 以 参见 https://github.com/ReactivePlatform/Reactive-Programming- 
With-RxJava, 也 欢迎 各 位 读者 一 起 参与 这 项 工作 。 为 了 本 书 的 完整 性 , 书 中 的 源 代码 不 再 进 
行 单独 调整 。 

在 本 书 的 翻译 过 程 中 我 得 到 了 何 品 的 很 多 帮助 和 指导 ， 在 此 表示 感谢 。 同 时 感谢 图 灵 公司 
的 朱 者 老师。 另外 ， 还 要 感谢 我 的 家 人 ， 他 们 包容 并 且 支 持 我 把 大 量 的 业余 时 间 都 投入 到 
了 本 书 的 翻译 之 中 。 

虽然 在 本 书 的 翻译 过 程 中 我 花费 了 较 长 的 时 间 去 其 酌 和 修改 ,但 是 限于 我 的 知识 水 
平 ， 难 免 会 有 丝 漏 ， 欢 迎 读者 指正 。 读 者 可 以 通过 1levinzhang1981@126.com 或 者 微 信 
levinzhang1981 联系 我 。 


希望 这 本 书 对 读者 有 用 ， 视 阅读 愉快 ! 


























xiv | 译 者 序 





2005 年 10 月 28 日 ， 微 软 新 任命 的 首席 架构 师 Ray Ozzie 以 邮件 的 形式 给 员工 发 布 了 一 份 
著名 的 备忘录 ， 即 “互联 网 服务 时 代 来 临 ”(The Internet Services Disruption) 。 在 这 份 备 忘 
录 中 ，Ozzie 概述 了 微软 、 人 谷歌、 亚马逊 和 Netflix 使 用 Web 作为 交付 服务 的 主要 渠道 给 世 
界 带 来 的 变化 。 

从 开发 人 员 的 角度 ，Ozzie 为 大 型 企业 的 管理 者 做 了 以 下 重要 声明 。 


复杂 性 具有 杀伤 力 。 它 会 吞噬 开发 人 员 的 生命 力 ， 让 产品 难以 规划 、 构 建 和 

测试 ， 带 来 安全 性 方面 的 挑战 ， 而 且 还 会 给 终端 用 户 和 管理 员 带 来 挫败 感 。 
首先 ， 我 们 要 考虑 的 是 2005 年 时 大 型 IT 企业 非常 喜欢 复杂 的 技术 ， 如 SOAP、WS-* 和 
XML。 当 时 “微服 务 ”这 个 词 还 没有 出 现 ， 没 有 简单 的 技术 帮助 小 企业 的 开发 人 员 管 理 异 
步 组 合 复杂 服务 的 复杂 性 ， 同 时 缺少 处 理 失 败 、 延 迟 、 安 全 性 和 效率 的 技术 。 
对 于 我 在 微软 的 Cloud Programmability 团队 来 说 ，Ozzie 的 备忘录 是 一 口 能 发 出 振 舍 发 职 
声音 的 警钟 ， 提 醒 我 们 要 专注 于 发 明 一 种 简单 的 编程 模型 ， 用 于 构建 大 规模 异步 和 数据 密 
集 型 的 互联 网 服务 架构 。 在 经 历 过 多 次 失败 之 后 ， 我 们 团队 终于 明白 ， 通 过 对 同步 集合 的 
Iterable/Iterator 接口 进行 二 元 化 (dualizing) 处 理 ， 可 以 得 到 一 对 表示 异步 事件 流 的 接口 ， 
以 及 所 有 熟悉 的 序列 操作 符 ， 比 如 map、filter、scan、zip、groupBy 等 ， 它 们 能 够 转换 和 
组 合 异步 的 数据 流 ， 因 此 ，2007 年 夏天 Rx 应 运 而 生 。 在 实现 过 程 中 ， 我 们 意识 到 需要 管 
理 并 发 和 时 间 ， 为 此 扩展 了 Java executor 理念 ， 提 供 了 虚拟 时 间 和 协同 重新 调度 的 功能 。 


经 过 两 年 密集 的 编程 马拉松 ， 我 们 团队 探索 了 大 量 的 设计 方案 以 供 选 择 ， 并 在 2009 年 11 
月 18 日 先 推出 了 Rx.NET。 不 久 ， 我 们 将 Rx 移植 到 了 针对 Windows Phone 7 的 Microsoft. 
Phone.Reactive 上 ， 并 且 开 始 在 其 他 语言 (如 JavaScript 和 C++) 中 实现 Rx， 还 用 Ruby 和 
Objective-C 提供 了 实验 性 版 本 。 

在 微软 内 部 ， 第 一 个 使 用 Rx 的 用 户 是 Jafar Husain， 他 在 2011 年 加 入 Netflix 的 时 候 将 这 
项 技术 带 到 了 那里 。Jafar 在 Netflix 大 力 宣传 Rx， 最 终 为 Netflix UI 的 客户 端 栈 重建 了 全 
新 的 架构 ， 以 完全 支持 异步 流 处 理 。 对 于 我 们 来 说 非常 幸运 的 是 ， 他 将 自己 的 热情 “ 传 









































































































































XV 


递 ”给 了 本 克 里 斯 滕 森 。 当 时 本 正 致力 于 Netflix 中 间 层 API 的 工作 ， 因 为 Netflix 在 中 
间 层 使 用 Java， 所 以 本 在 2012 年 开始 了 RxJava 的 工作 ， 并 在 2013 年 初 将 代码 库 转移 到 
了 GitHub 上 以 便于 持续 的 开源 开发 。 微 软 中 另外 一 个 较 早 的 Rx 采用 者 是 Paul Betts， 他 
在 去 GitHub 工作 之 后 成 功 地 说 服 了 GitHub 的 同事 (如 Justin Spahr-Summers) 实现 并 在 
2012 年 的 春天 发 布 了 针对 Objective-C 的 ReactiveCocoa。 


随 着 Rx 在 业界 越 来 越 流 行 ， 我 们 在 2012 年 秋天 说 服 微软 Open Tech 开源 了 Rx.NET。 此 
后 不 入 ， 我 离开 微软 并 创建 了 Applied Duality 公司 ， 并 将 全 部 时 间 用 于 使 Rx 成 为 标准 的 
跨 语言 和 跨 平台 的 API[， 以 异步 实时 处 理 数据 流 。 


时 间 很 快 来 到 2016 年 ，Rx 越 来 越 受 欢迎 ， 使 用 范围 也 急速 扩大 。Netflix API 的 所 有 流 
量 都 基于 RxJava，Hystrix 容错 库 也 依赖 于 RxJava， 该 库 隔 离 了 所 有 的 内 部 服务 流量 。 通 
过 相关 的 反应 式 库 RxNetty 和 Mantis，Netflix 正在 创建 一 个 完全 反应 式 的 网 络 栈 ， 用 于 
跨 机 器 和 进程 边界 连接 所 有 的 内 部 服务 。RxJava 在 Android 领域 也 取得 了 巨大 的 成 功 ， 
SoundCloud、Square、NYT、Seatgeek 等 公司 的 Android 应 用 程序 都 在 使 用 RxJava， 并 为 
RxAndroid 扩展 库 贡 献 了 力量 。NoSQL 厂商 ， 如 Couchbase 和 Splunk， 为 它们 的 数据 访问 
层 提供 了 基于 Rx 的 绑 定 功能 。 其 他 采用 RxJava 的 Java 库 包 括 Camel Rx、Square Retrofit 
和 Vertx。RxJS 被 JavaScript 社区 广泛 采用 ， 并 为 Angular 2 等 流行 框架 提供 了 强大 的 支 
持 。 该 社区 维护 了 一 个 网 站 (http:/reactivex.io/) ， 在 那里 可 以 找到 许多 语言 中 Rx 实现 的 
相关 信息 ， 以 及 精美 的 弹 珠 图 和 David Gross (@CallHimMoorlock) 的 阐述 。 


自 诞生 起 ，Rx 就 随 着 开发 者 社区 的 需求 和 输入 而 不 断 发 展 。 在 .NET 中 ，Rx 的 最 初 实现 
只 专注 于 转换 异步 事件 流 ， 并 在 需要 回 压 的 场景 使 用 异步 枚 举 (asynchronous enumerable)。 
由 于 Java 没有 对 异步 await 的 语言 级 支持 ， 开 发 者 社区 使 用 反应 式 拉 取 的 概念 扩展 了 
Observer 和 Observable 类 型 ， 并 引入 了 Producer 接口 。 由 于 有 许多 开源 贡献 者 ，RxJava 的 
实现 非常 复杂 ， 但 是 经 过 了 高 度 优 化 。 


尽管 RxJava 的 细节 与 其 他 Rx 实现 有 细微 的 差异 ， 但 是 它 依然 是 专门 为 全 新 的 分 布 式 实时 
数据 处 理 领 域 的 开发 人 员 创建 的 ， 让 他 们 能 够 专注 于 本 质 复 杂 性 ， 而 不 会 为 偶发 复杂 性 所 
折磨 。 本 书 深入 探讨 了 RxJava 的 概念 和 使 用 ， 以 及 Rx 的 通用 理念 。 两 位 作者 在 实现 和 使 
用 RxJava 方面 拥有 丰富 的 经 验 。 如 果 你 想 学 习 Java 反应 式 编程 ， 没 有 比 购买 本 书 更 好 的 
方法 了 。 










































































Erik Meijer 
Applied Duality 公司 总 裁 和 创始 人 








本 书目 标 读者 





到 
Ml 


本 书 适合 中 级 和 高 级 Java 程序 员 。 你 应 该 非常 熟悉 Java， 但 是 并 不 需要 预先 掌握 反应 式 


浴 








识 。 以 下 两 类 程序 员 都 能 从 本 书 中 获 益 。 
。 想 提 升 服务 器 性 能 或 者 想 让 移动 设备 的 代码 更 具 可 维护 性 的 软件 工程 师 。 如 果 你 属于 这 





一 类 的 话 ， 将 会 在 本 书 中 找到 解决 实际 问题 的 型 





























种 情况 下 ，RxJava 只 是 本 书 帮助 你 掌握 的 男 一 个 工具 。 
。 好 奇 的 开发 人 员 。 他 们 可 能 昕 说 过 反应 式 编程 , 尤其 是 RxJava, 并 且 想 要 真正 地 理解 它 。 
如 果 你 属于 这 种 情况 ， 即 使 没 计划 在 生产 环境 的 代码 中 使 用 RxJava， 本 书 也 会 开拓 你 





的 视野 。 


另外 ， 如 果 你 是 一 名 真正 的 软件 架构 师 ， 本 和 








程 的 知识 。 本 书 中 的 很 多 概念 都 与 函数 式 编程 相关 ， 不 过 你 也 无 须 预先 了 解 这 方面 的 知 





E 念 和 方案 ， 还 有 切实 中 肯 的 建议 。 在 这 











区 很 可 能 会 对 你 有 所 帮助 。RxJava 会 影响 整 


个 系统 的 总 体 架构 ， 所 以 值得 去 了 解 。 即 便 你 刚刚 体验 编程 ， 也 可 以 尝试 翻阅 本 书 的 前 几 


章 ， 这 几 章 介 绍 了 基础 知识 。 一 些 底层 的 到 


式 编程 特有 的 。 





本 克 里 斯 滕 森 的 说 明 
2012 年 ， 我 正在 为 Netfix API 实现 一 种 新 的 架构 。 在 这 个 过 程 中 逐渐 明确 的 是 ， 为 了 实 


现 目 标 ， 我 们 需要 拥抱 并 发 和 异步 网 络 请 求 。 在 探索 实现 方式 的 过 程 中 ， 我 遇 到 了 Jafar 
Husain， 他 努力 向 我 “兜售 ”他 在 微软 学 到 的 名 为 “Rx” 的 方法 。 我 当时 虽然 非常 熟悉 并 


发 ， 但 是 依然 按照 命令 式 的 方式 进行 思 芳 ， 并 且 








的 经 济 支柱 ， 我 在 它 上 面 花费 了 大 量 时 间 。 


Jafar 向 我 “兜售 ”Rx 方法 时 ， 











E 念 是 通用 的 ， 如 转换 和 组 合 ， 它 们 并 不 是 反应 











[极度 以 Java 为 中 心 ， 因 为 Java 一直 是 我 




















因 其 函数 式 编程 风格 ， 我 很 鸡 





理解 这 些 理念 ， 只 能 先 搁置 。 
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在 数 月 的 讨论 之 后 ， 整 体 的 系统 架构 不 断 成 熟 。 在 这 个 过 程 中 ， 我 和 Jafar 继续 进行 了 多 
次 白板 会 议 ， 直 到 我 掌握 了 这 些 理论 原则 ， 并 且 意 识 到 Reactive Extensions 的 优雅 和 力量 。 


我 们 决定 在 Netflix API 中 采用 Rx 编程 模型 ， 最 终 创建 了 Reactive Extensions 的 Java 实现 ， 
即 RxJava， 它 遵循 了 微软 从 Rx.Net 和 RxJS 开始 的 命名 约定 。 


在 我 从 事 RxJava 开发 工作 的 大 约 三 年 间 ， 大 部 分 工作 都 是 在 GitHub 上 以 开放 的 方式 完成 
的 。 我 有 幸 与 一 个 不 断 成 长 的 社区 一 起 工作 ，120 多 位 贡献 者 一 起 将 RxJava 变 成 了 一 个 成 
熟 的 产品 ， 它 被 用 于 很 多 生产 系统 中 的 服务 器 端 和 客户 端 。 在 GitHub 上 它 获得 了 15 000 
多 颗 星 ， 成 为 了 排名 前 200 名 的 项 目 之 一 ， 同 时 在 使 用 Java 的 项 目 中 排名 第 三 。 

Netflix 的 George Campbell、Aaron Tull 和 Matt Jacobs 在 RxJava 成 熟 的 过 程 中 起 着 关键 作 
用 ， 他 们 将 RxJava 从 早期 的 构建 版 本 变 成 了 现在 的 样子 ， 所 做 的 工作 包括 添加 了 Lift、 
Subscriber、 回 压 以 及 JVM 多 语言 支持 。Divid Karnok 随后 参与 了 进来 ， 他 提交 代码 的 次 
数 和 行 数 都 已 经 超过 了 我 。 他 是 项 目 取得 成 功 的 关键 因素 之 一 ， 并 且 已 成 为 项 目的 领导 者 。 


我 必须 要 感谢 Erik Meijer， 他 在 微软 期 间 创 建 了 Rx。 在 他 离开 微软 之 后 ， 我 曾 在 Netflix 
就 RxJava 项 目 与 他 合作 过 。 现 在 ， 我 有 地 和 他 一 起 在 Facebook 工作 。 和 他 在 白板 前 花 那 
么 多 的 时 间 一 起 讨论 是 我 的 来 幸 。Erik 这 样 的 良师益友 大 大 提高 了 我 的 思想 水 平 。 


在 这 个 过 程 中 ， 我 还 在 很 多 会 议 上 阐述 了 RxJava 和 反应 式 编程 的 相关 内 容 ， 并 结识 了 很 
多 人 ， 他 们 帮助 我 学 习 了 关于 代码 和 架构 的 更 多 知识 。 如 有 果 是 自学 的 话 ， 我 不 可 能 学 到 这 
么 多 。 


Netflix 支持 我 在 这 个 项 目 上 花费 时 间 和 精力 ， 并 且 在 技术 文档 方面 提供 了 支持 。 我 自己 可 
能 永远 也 写 不 出 这 样 的 文档 。 如 果 没 有 “工作 时 间 ” 的 付出 和 拥有 不 同 技能 的 许多 人 员 的 
参与 ， 这 种 成 熟 度 和 规模 的 开源 项 目 是 无 法 取得 成 功 的 。 

在 第 1 章 中 ， 我 会 试图 讲解 为 何 反应 式 编程 是 一 种 有 用 的 编程 方式 ， 以 及 RxJava 是 如 何 
具体 实现 这 些 原则 的 。 

本 书 其 余部 分 由 托 马 什 编写 ， 他 写 得 非常 棒 。 我 有 机 会 审阅 并 提 了 一 些 建 议 ， 但 这 是 他 的 
书 ， 从 第 2 章 开始 他 将 负责 详细 内 容 的 讲解 。 


托 马 什 . 努 尔 凯 维 茨 的 说 明 


2013 年 ， 我 在 一 家 金融 机 构 工作 的 时 候 ， 第 一 次 接触 RxJava。 当 时 ， 我 们 要 实时 处 理 大 
量 市 场 数据 。 那 时 数据 管道 的 组 成 是 这 样 的 : Kafka 传递 消息 ，Akka 处 理 交 易 ，Clojure 转 
换 数据 ， 还 有 一 个 自 定义 构建 的 语言 在 整个 系统 中 传播 变更 。RxJava 是 一 个 非常 具有 吸引 
力 的 选择 ， 因 为 它 有 一 个 统一 的 API， 能 够 很 好 地 处 理 不 同 来 源 的 数据 。 


随 着 时 间 的 推移 ， 我 尝试 在 更 多 的 场景 中 使 用 反应 式 编程 。 在 这 些 场景 中 ， 可 扩展 性 和 吞 
吐 量 都 至 关 重 要 。 按 照 反应 式 的 方式 来 实现 系统 肯定 要 求 更 高 ， 但 是 它 带 来 的 好 处 更 为 重 
要 ， 包 括 更 高 的 硬件 利用 率 以 及 由 此 带 来 的 能 源 节省 。 为 了 充分 理解 这 种 编程 模型 的 优 
势 ， 开 发 人 员 必 须 拥 有 相对 易 用 的 工具 。 我 们 认为 Reactive Extensions 在 抽象 、 复 杂 性 以 
及 性 能 之 间 实现 了 平衡 。 









































































































































除非 特别 说 明 ， 本 书 讲述 的 是 RxJava 1.1.6 版 本 。 尽 管 RxJava 支持 Java 6 及 更 高 版 本 ,但 
是 几乎 所 有 的 示例 都 用 到 了 Java 8 中 的 lambda 语法 。 在 讨论 Android 的 第 8 章 中 ， 有 些 示 
例 展现 了 如 何在 不 支持 lambda 表达 式 的 环境 中 处 理 烦 琐 的 语法 。 话 虽 如 此 ， 本 书 并 不 会 
一 直 采 用 最 简短 的 语法 (比如 方法 引用 )， 这 主要 是 为 了 在 适当 的 场景 下 提升 代码 可 读 性 。 


本 书 结构 


如 果 你 从 头 读 到 尾 的 话 ， 将 会 收获 最 大 。 如 果 你 没有 那么 多 的 时 间 ， 也 可 以 选择 最 感 兴 趣 
的 部 分 。 如 果 某 个 概念 在 本 书 前 面 的 章 市 中 介绍 过 了 ， 那 么 你 很 可 能 会 找到 关于 参考 章 市 
的 说 明 。 如 下 是 各 章 的 简要 介绍 。 


第 1 章 简要 介绍 RxJava 的 起 源 、 基 本 概念 以 及 理念 (本 )。 
第 2 章 讨 论 如 何 将 RxJava 用 于 自己 的 应 用 程序 ， 以 及 如 何 与 它 交互 。 这 一 章 非 常 基础 ， 
































第 3 章 快 速 介绍 RxJava 提供 的 很 多 操作 符 ， 讲 解 一 些 具有 表现 力 且 强大 的 函数 ， 它 们 是 
这 个 库 的 基础 ( 托 马 什 )。 


第 4 章 更 加 实用 ， 展 现 如 何 将 RxJava 骨 入 代码 库 的 不 同 地 方 ， 还 会 简单 介绍 并 发 性 〈 托 
马 什 )。 


第 5 章 内 容 更 高 级 ， 阐 述 如 何 从 头 到 尾 实现 反应 式 应 用 程序 ( 托 马 什 )。 


第 6 章 解 释 流 控 制 中 一 个 非常 重要 的 问题 ， 并 介绍 RxJava 中 的 回 压 机 制 是 如 何 解决 该 问 
题 的 〈 托 马 什 )。 


第 7 章 介 绍 基于 Rx 的 应 用 程序 的 单元 测试 、 维 护 以 及 问题 排查 等 相关 技术 ( 托 马 什 )。 
第 8 章 展现 一 些 RxJava 应 用 程序 ， 尤 其 是 分 布 式 系统 中 的 程序 〈 托 马 什 )。 
第 9 章 重 点 介绍 RxJava 2.x 未 来 的 计划 (本 )。 


在 线 资源 


本 书 所 有 的 弹 珠 图 均 来 源 于 RxJava 的 官方 文档 ， 它 们 基于 Apache 许可 证 2.0 版 本 发 布 。 


排版 约定 

本 书 使 用 了 下 列 排版 约定 。 
表示 新 术语 或 重点 强调 的 内 容 。 

等 宽 字 体 (constant width) 
表示 程序 片段 ， 以 及 正文 中 出 现 的 变量 、 函 数 名 、 数 据 库 、 数 据 类 型 、 环 境 变 量 、 语 句 
和 关键 字 等 。 















































加 粗 等 宽 字 体 (constant width bold) 
表示 应 该 由 用 户 输入 的 命令 或 其 他 文本 。 


等 宽 和 斜体 (constant width italic) 
表示 应 该 由 用 户 输入 的 值 或 根据 上 下 文 确定 的 值 赫 换 的 文本 。 











该 图 标 表 示 提 示 或 建议 。 








该 图 标 表示 一 般 注 记 。 





该 图 标 表 示警 告 
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Safari” Books Online 


Safari Books Online (http:/www.safaribooksonline.com) 是 应 运 而 生 的 数字 图 书馆 。 它 同时 
以 图 书 和 视频 的 形式 出 版 世界 顶级 技术 和 商务 作家 的 专业 作品 。 技 术 专 家 、 软 件 开发 人 
员 、Web 设计 师 、 商 务 人 士 和 创意 专家 等 ， 在 开展 调研 、 解 决 问题 、 学 习 和 认证 培训 时 ， 
都 将 Safari Books Online 视 作 获取 资料 的 首选 渠道 。 

对 于 组 织 团体 、 政 府 机 构 和 个 人 ，Safari Books Online 提供 各 种 产品 组 合 和 灵活 的 定 
价 策略 。 用 户 可 通过 一 个 功能 完备 的 数据 库 检 索 系 统 访问 O’Reilly Media、Prentice 
Hall Professional、Addison-Wesley Professional、 Microsoft Press、Sams、Que、Peachpit 

















Press、 Focal Press、Cisco Press、John Wiley & Sons、 Syngress、 Morgan Kaufmann、IBM 
Redbooks、 Packt、Adobe Press、 FT Press、Apress、Manning、New Riders、McGraw-Hill、 
Jones 及 Bartlett、Course Technology 以 及 其 他 几 十 家 出 版 社 的 上 千 种 图 书 、 培 训 视频 和 正 
式 出 版 之 前 的 书稿 。 要 了 解 Safari Books Online 的 更 多 信息 ， 我 们 网 上 见 。 


联系 我 们 
请 把 对 本 书 的 评价 和 问题 发 给 出 版 社 。 


美国 : 


O’Reilly Media, Inc. 
1005 Gravenstein Highway North 
Sebastopol, CA 95472 
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中 国 : 
北京 市 西城 区 西直门 南大 街 2 号 成 铭 大 厦 C 座 807 室 (100035) 
奥 莱 利 技术 咨询 (北京 ) 有 限 公 司 
O’Reilly 的 每 一 本 书 都 有 专属 网 页 ， 你 可 以 在 那儿 找到 本 书 的 相关 信息 ， 包 括 勘误 表 、 示 
例 代 码 以 及 其 他 信息 。 本 书 的 网 站 地 址 是 http://bit.ly/reactive-prog-with-rxjava。 
对 于 本 书 的 评论 和 技术 性 问题 ， 请 发 送 电子 邮件 到 : bookquestions@oreilly.com 
要 了 解 更 多 O'Reilly 图 书 、 培 训 课程 、 会 议和 新 闻 的 信息 ， 请 访问 以 下 网 站 ; 
http://www.oreilly.com 
我 们 在 Facebook 的 地 址 如 下 : http://facebook.com/oreilly 
请 关注 我 们 的 Twitter 动态 : http://twitter.com/oreillymedia 
我 们 的 YouTube 视频 地 址 如 下 : http://www.youtube.com/oreillymedia 
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感谢 托 马 什 在 Twitter 上 答复 我 寻找 作者 的 消息 ， 最 终 将 这 本 书 变 成 现实 。 
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电子 书 


扫描 如 下 二 维 码 ， 即 可 购买 本 书 中 文 电子 版 。 


























xxii | 前 言 


第 1 章 


使 用 RxJava 实 现 反 应 式 编程 





本 . 克 里 斯 滕 森 〈(Ben Christensen ) 


RxJava 是 对 Java 和 Android 进行 反应 式 编程 的 具体 实现 ， 它 受到 了 函数 式 编程 的 影响 。 
RxJava 倡导 函数 组 合 ， 避 免 出 现 全 局 状态 和 副作用 ， 并 且 要 以 流 的 方式 思考 ， 进 而 组 合 异 
步 和 基于 事件 的 程序 。 它 起 源 于 观察 者 模式 (observer pattern) 的 生产 者 / 消费 者 回调 ， 并 
且 扩 展 了 几 十 个 操作 符 来 实现 组 合 、 转 换 、 调 度 、 市 流 、 错 误 处 理 以 及 生命 周期 管理 。 


RxJava 是 一 个 成 熟 的 开源 库 ， 已 经 被 服务 器 端 和 Android 移动 设备 广泛 采用 。 除 了 这 个 库 
之 外 ， 开 发 人 员 还 围绕 RxJava 和 反应 式 编程 构建 了 一 个 活跃 的 社区 ， 主 要 用 来 改进 项 目 、 
互相 交流 、 撰 写 文章 以 及 提供 帮助 。 

这 一 章 将 概述 RxJava， 讨 论 什么 是 RxJava， 以 及 它 如 何 运 行 。 本 书 的 其 余部 分 会 带 你 了 解 
RxJava 的 全 部 细节 ， 以 及 如 何 将 其 用 于 应 用 程序 。 你 在 阅读 本 书 的 时 候 ， 可 以 没有 任何 反 
应 式 编 程 的 经 验 ， 因 为 本 书 会 从 头 开 始 ， 带 领 你 了 解 RxJava 的 理念 和 实践 ， 以 便 将 它 的 
优势 应 用 到 具体 用 例 中 。 


1.1 反应 式 编 程 与 RxJava 


反应 式 编程 (reactive programming) 是 一 个 通用 的 编程 术语 ， 它 主要 关注 对 变更 做 出 反 
应 ， 比 如 数据 值 或 事件 。 反 应 式 编程 通常 可 以 按照 命令 式 (imperative) 的 方式 来 实现 。 
回调 就 是 一 种 以 命令 式 实 现 反应 式 编程 的 方法 。 电 子 表格 是 反应 式 编程 的 一 个 绝 佳 例 子 : 
某 些 单 元 格 依赖 于 其 他 的 单元 格 ， 如 果 被 依赖 的 单元 格 发 生变 化 ， 这 些 单 元 格 也 会 随 之 
“做 出 反应 ”。 














































































































函数 式 反应 编程 ? 

尽管 Reactive Extensions (通常 指 Rx， 特 指 的 话 是 RxJava) 受到 了 函数 式 编程 的 影响 ， 
但 它 并 不 是 函数 式 反应 编程 (Functional Reactive Programming，FRP)。FRP 是 非常 具 
体 的 一 种 反应 式 编程 类 型 ， 它 涉及 连续 的 时 间 ， 而 RxJava 只 处 理 随 时 间 推 移出 现 的 
离散 事件 。 在 RxJava 的 早期 ， 我 本 人 也 陷入 了 这 样 的 命名 陷阱 ， 将 其 宣传 为 “函数 式 
反应 "”， 后 来 我 发 现 “函数 式 反 应 ”在 数 年 前 就 已 经 被 别人 定义 了 。 因 此 除了 “反应 
式 编程 ”之 外 ， 没 有 一 个 公认 的 通用 术语 来 描述 RxJava。FRP 还 是 经 常 被 误 用 于 描述 
RxJava 和 类 似 的 方案 。 对 于 是 应 该 拓展 FRP 的 含义 (因为 在 过 去 的 几 年 间 ， 它 已 经 被 
非 正式 地 使 用 了 )， 还 是 让 FRP 止 于 关注 连续 时 间 的 实现 ， 互 联网 上 也 时 有 争论 。 


为 了 消除 疑虑 ， 可 以 把 重点 放 在 RxJava 确实 受到 了 函数 式 编程 的 影响 ， 并 且 有 意 地 采 
取 了 与 命令 式 编程 不 同 的 编程 模型 。 这 一 章 提 到 “反应 式 ” 时 ， 指 的 是 RxjJava 使 用 的 
反应 式 二 函数 式 风格 。 与 之 相对 ， 提 到 “命令 式 ” 时 ， 并 不 是 说 反应 式 编程 不 能 以 命 
令 式 的 方式 实现 ， 强 调 的 是 使 用 命令 式 的 方式 来 编程 ， 而 不 是 RxJava 的 函数 式 风格 。 
专门 对 比 命令 式 方式 和 有 子 数 式 方式 时 ， 为 了 准确 起 见 ， 会 使 用 “反应 式 一 函数 式 ” 和 
“反应 式 一 命令 式 ”。 











在 现在 的 计算 机 中 ， 当 涉及 操作 系统 和 硬件 时 ， 一 切 都 会 变 成 命令 式 的 。 开 发 人 员 必 须 明 确 
告诉 计算 机 要 完成 什么 以 及 如 何 实现 。 人 类 不 会 像 CPU 和 相关 系统 那样 思考 ， 所 以 我 们 添 
加 了 抽象 。 反 应 式 - 了 尔 数 式 编程 就 是 一 种 抽象 ， 就 像 高 层级 命令 式 编程 术语 是 对 底层 二 进 制 
和 汇编 指令 的 抽象 一 样 。 记 住 并 理解 “一 切 都 会 变 成 命令 式 的 ”很 重要 ， 因 为 它 能 够 帮助 理 
解 反 应 式 - 函数 式 编程 的 思维 模型 ， 并 理解 它 最 终 是 如 何 执 行 的 ， 这 里 并 没有 什么 魔法 。 


因此 ， 作 为 一 种 编程 方式 ， 反 应 式 - 函数 式 编程 是 命令 式 系统 之 上 的 一 种 抽象 。 它 允许 开 
发 人 员 在 编写 异步 和 事件 驱动 的 用 例 时 不 用 像 计算 机 本 身 那 样 思考 ， 也 不 用 以 命令 式 的 方式 
来 定义 复杂 的 状态 交互 ， 尤 其 是 跨 线程 和 网 络 边 界 时 。 在 处 理 异步 和 事件 驱动 的 系统 时 ， 不 
用 像 计 算 机 那样 思考 是 一 项 有 用 的 特质 ， 因 为 这 种 情况 会 涉及 并 发 和 并 行 ， 而 要 正确 和 高 效 
地 使 用 这 些 功能 是 非常 具有 挑战 性 的 。Brian Goetz 的 著作 《Java 并 发 编程 实战 》 Doug Lea 
的 著作 Concurrent Programming in Java 以 及 像 Mechanical Sympathy 这 样 的 论坛 ， 都 表明 了 掌 
握 并 发 所 面临 的 深度 、 广 度 以 及 复杂 性 。 使 用 RxJava 以 来 ， 通 过 与 这 些 书 的 作者 、 论 坛 和 
社区 的 专家 的 交流 ， 我 更 加 确信 编写 高 性 能 、 高 效 、 可 扩展 和 正确 处 理 并 发 的 软件 相当 不 容 
易 。 这 还 没有 将 分 布 式 系统 考虑 进来 呢 ， 它 将 并 发 性 和 并 行 性 的 难度 提高 了 一 截 。 

所 以 ， 简 而 言 之 ， 反 应 式 - 函数 式 编 程 解决 的 问题 就 是 并 发 和 并 行 。 更 通俗 地 说 ， 它 解决 
了 回调 地 狱 问 题 。 回 调 地 狱 是 以 命令 式 的 方式 来 处 理 反应 式 和 异步 用 例 带 来 的 问题 。 反 应 
式 编 程 ， 比 如 RxJava 实现 ， 受 到 了 函数 式 编 程 的 影响 ， 并 且 会 使 用 声明 式 的 方式 来 避免 
反应 式 - 命令 式 代码 常见 的 问题 。 


1.2 何 时 需要 反应 式 编程 


反应 式 编 程 在 如 下 场景 中 非常 有 用 。 
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处 理 用 户 事件 ,比如 鼠标 移动 和 单 击 、 键 盘 输 入 .GPS 信和 号 因 用 户 设备 的 移动 而 不 断 变化 、 
设备 陀螺 仪 信号 和 触摸 事件 等 。 

响应 和 处 理 来 自 磁盘 或 网 络 的 所 有 延迟 受 限 的 IO 事件 , IO 本 质 上 是 异步 的 (发 起 请 求 ， 
时 间 推 移 ， 可 能 收 到 也 可 能 收 不 到 响应 ， 触 发 下 一 步 事 件 )。 

。 在 应 用 程序 中 处 理由 该 应 用 程序 无 法 控制 的 生产 者 推送 过 来 的 事件 或 数据 (来 自 服务 器 
的 系统 事件 、 上 述 用 户 事件 、 来 自 硬件 的 信号 、 模 拟 世 界 中 由 传感器 触发 的 事件 等 )。 
如 果 涉 及 的 代码 只 处 理 一 个 事件 流 ， 那 么 使 用 带 有 回调 的 反应 式 - 命令 式 编程 就 很 好 ， 引 入 
反应 式 -函数 式 编程 并 不 会 带 来 太 多 的 收益 。 如 果 你 有 数 百 个 不 同 的 事件 流 ， 而 且 它 们 彼此 
独立 ， 命 令 式 编 程 也 不 会 有 太 大 的 问题 。 在 这 种 直接 的 使 用 场景 中 ， 命 令 式 是 最 高 效 的 方 
式 ， 因 为 它 消 除了 反应 式 编程 的 抽象 层 ， 并 且 更 加 契合 对 当前 操作 系统 、 语 言 和 编译 器 的 

优化 。 

如 果 你 的 程序 像 大 多 数 程序 一 样 ， 那 么 你 需要 组 合 事件 (或 者 函数 或 网 络 调用 的 异步 响 
应 )、 包 含 事件 交互 的 条 件 逻 辑 ， 而 且 在 所 有 调用 之 后 必须 处 理 故 障 场景 和 清理 资源 。 在 
这 种 情况 下 ， 反 应 式 - 命令 式 的 复杂 性 会 急剧 增加 ， 而 反应 式 - 函数 式 编程 则 能 体现 出 它 
的 价值 了 。 我 认同 一 个 未 经 科学 验证 的 观点 ， 那 就 是 反应 式 - 函数 式 编程 难 入 门 而 且 学 习 
曲线 较 陡 峭 ， 但 是 它 的 复杂 性 要 远 远 低 于 反应 式 - 命令 式 编 程 。 
这 就 是 称 Reactive Extensions (Rx) 和 RxJava 是 “用 于 组 合 异 步 和 基于 事件 的 程序 的 库 ? 
的 原因 。RxJava 是 反应 式 编程 原则 的 具体 实现 ， 受 到 了 函数 式 以 及 数据 流 编程 的 影响 。 其 
实 ， 我 们 有 不 同 的 方式 来 实现 “反应 式 ”，RxJava 只 是 其 中 之 一 。 接 下 来 深入 研究 一 下 它 
是 如 何 运 行 的 。 


1.3 ”RxJava 是 如 何 运行 的 


RxJava 的 核心 是 0bservable 类 型 ， 它 代表 了 数据 或 事件 的 流 。 它 的 目的 是 实现 推送 (反应 
式 )， 但 是 也 可 以 用 于 拉 取 (交互 式 )。 它 是 延迟 执行 的 〈lazy) ， 不 是 立即 执行 的 〈eager) 。 
它 可 以 同步 使 用 ， 也 可 以 异步 使 用 。 它 能 够 代表 随 着 时 间 推 移 产生 的 0 个 、1 个 、 多 个 或 
者 无 穷 个 值 或 事件 。 


这 涉及 很 多 的 术语 和 细节 ， 需 要 一 一 介绍 ，2.1 市 将 介绍 完整 的 细 市 。 


1.3.1 推送 与 拉 取 

RxJava 实现 反应 式 的 要 点 在 于 它 支 持 推送 ， 所 以 0bservable 和 关联 的 0bserver 类 型 签名 
支持 把 事件 推送 给 它 。 这 通常 会 伴随 着 异步 ，1.3.2 节 会 进行 讨论 。 但 是 ，0bservable 类 型 
还 支持 一 个 异步 的 反馈 通道 (有 时 也 称 为 异步 - 拉 取 或 反应 式 拉 取 )， 作 为 异步 系统 中 的 
一 种 流 控制 或 回 压 方式 。 本 章 后 面 会 讨论 流 控制 ， 以 及 如 何 使 用 该 机 制 。 

为 了 支持 接收 推送 来 的 事件 ，0bservable/0bserver 通过 订阅 进行 连接 。0bservable 代表 了 
数据 流 ， 它 可 以 被 Observer 订阅 (2.2 节 会 介绍 更 多 内 容 )。 


interface Observable<T> { 
Subscription subscribe(Observer s) 
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订阅 之 后 ，0bserver 就 能 够 接收 三 种 推送 给 它 的 事件 。 


。 通过 onNext() 函数 推送 的 数据 。 
。 通过 onError() 函数 推送 的 错误 (异常 或 Throwable)。 
。 通过 onCompleted() 函数 推送 的 流 完成 信息 。 
interface Observer<T> { 
void onNext(T t) 


void onError(Throwable t) 
void onCompleted() 








} 
其 中 ，onNext() 可 能 永远 也 不 会 被 调用 ， 也 可 能 会 被 调用 一 次 、 多 次 或 无 数 次 。onError() 
和 onCompleted() 是 终端 事件 ， 这 意味 着 两 者 只 能 有 一 个 被 调用 ， 并 且 只 能 被 调用 一 次 。 
终端 事件 被 调用 之 后 ，0bservable 流 就 完成 了 ， 以 后 就 不 能 再 向 它 发 送 事件 了 。 如 果 流 是 
无 限 的 ， 并 且 没 有 发 生 故 障 ， 那 么 终端 事件 可 能 永远 不 会 发 生 。 
6.1 节 和 6.2 节 将 会 展示 另外 一 种 类 型 签名 ， 它 支持 交互 式 拉 取 。 


interface Producer { 
void request(Long n) 





















































} 
它 可 以 与 更 加 高 级 的 0bserver 协同 使 用 ， 即 Subscriber (2.3 节 提 供 了 更 多 的 细节 )。 


abstract class Subscriber<T> implements Observer<T>, Subscription { 
void onNext(T t) 
void onError(Throwable +t) 
void onCompleted() 


void unsubscribe() 
void setPproducer(Producer p) 


Subscription 接口 中 包含 了 unsubcribe 函数 ,该 函数 能 够 允许 订阅 者 取消 对 某 个 
Observable 流 的 订阅 。setProducer 函数 和 Producer 类 型 用 来 在 生产 者 和 消费 者 之 间 建 立 
一 个 双向 的 通信 通道 ， 该 通道 用 于 流 控制 。 


1.3.2 ”异步 与 同步 

一 般 而 言 ，0bservable 是 异步 的 ， 但 它 并 非 总 是 如 此 。0bservablte 可 以 是 同步 的 ， 事 
实 上 ， 它 默认 就 是 同步 的 。 除 非 要 求 ， 否 则 RxJava 永远 不 会 添加 并 发 功能 。 同 步 的 
0bservable 将 被 订阅 ， 使 用 订阅 者 的 线程 发 布 (emit) 所 有 数据 并 且 完 成 (如 果 是 有 限 
Observable 的 话 ) 。 由 阻塞 式 网 络 IO 支撑 的 0bservable 将 会 同步 阻塞 订阅 线程 ， 并 在 阻 
塞 网 络 IO 返回 时 ， 通 过 onNext() 发 布 数据 。 


例如 ， 以 下 代码 示例 完全 是 同步 的 。 


Observable.create(s -> { 
s.onNext("Hello World!"); 
s.onCompleted(); 
}).subscribe(hello -> System.out.println(hello)); 
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2.2 节 和 2.4.1 节 将 介绍 Observable.create 和 0bservable.subscribe 的 更 多 知识 。 


现在 ， 你 可 能 会 想 ， 这 并 不 是 反应 式 系统 的 理想 行为 。 你 是 对 的 ! 将 同步 阻塞 IO 与 
0bservable 组 合 使 用 是 一 种 很 糟糕 的 形式 (如 果 确 实 要 使 用 阻塞 IO 的 话 ， 它 需要 以 线程 
的 方式 进行 异步 化 )。 但 是 ， 有 时 候 从 内 存 缓存 中 同步 获取 数据 并 立即 返回 也 是 一 种 恰当 
的 做 法 。 前 面 的 “Hello World” 样 例 并 不 需要 并 发 性 ， 事 实 上 ， 如 果 为 其 添加 异步 调度 的 
话 ， 它 将 会 慢 得 多 。 因 此 ， 通 常 来 讲 ， 实 际 上 重要 的 标准 是 0bservable 生成 事件 的 过 程 是 
阻塞 的 还 是 非 阻塞 的 ， 而 非 它 是 同步 的 还 是 异步 的 。 Hello World” 样 例 是 非 阻塞 的 ， 
为 它 永 远 不 会 阻塞 线程 ， 所 以 使 用 0bservable 是 正确 的 (尽管 看 上 去 有 些 多 余 ) 。 


实际 上 ，RxjJava 的 0bservable 不 知道 异步 与 同步 ， 也 不 知道 并 发 性 是 否 存在 以 及 来 自 何 
处 。 设 计 就 是 如 此 ， 这 允许 0bservable 的 实现 来 决定 什么 做 法 是 最 好 的 。 为 什么 说 这 是 有 
用 的 呢 ? 


首先 ， 并 发 性 可 以 来 自 多 个 地 方 ， 而 不 仅仅 是 线程 池 。 如 果 数 据 源 已 经 借助 事件 循环 
(event loop) 实现 了 异步 ， 那 么 RxJava 不 应 该 添加 更 多 的 调度 开销 或 者 强制 使 用 特定 的 调 
度 实现 。 并 发 性 可 以 来 自 线程 池 、 事 件 循环 、Actor 等 。 它 可 能 是 手动 添加 的 ， 也 可 能 3 
源 于 数据 源 。 异 步 性 来 自 何 处 ，RxJava 并 不 知晓 。 

其 次 ,使 用 同步 的 行为 有 两 个 很 好 的 理由 ， 下 面 会 进行 阐述 。 

1. 内 存 数据 

如 果 数 据 在 本 地 内 存 缓存 中 (查询 时 间 固 定 在 毫秒 / 纳 秒 级 别 )， 那 么 再 花费 调度 成 本 将 其 
异步 化 就 没有 意义 了 。0bservable 可 以 同步 地 获取 数据 ， 并 将 其 发 布 到 订阅 线程 上 ， 如 下 
所 示 。 


Observable.create(s -> { 
s.onNext(cache.get(SOME_KEY)); 
s.onCompleted(); 

}).subscribe(vaLue -> System.out.println(value)); 


不 清楚 数据 是 否 在 内 存 中 的 时 候 ， 调 度 选 择 是 很 重要 的 。 如 果 数 据 在 内 存 中 ， 就 采用 同步 
的 方式 进行 发 布 ， 如 果 不 在 内 存 中 ， 就 执行 异步 的 网 络 调用 ， 并 在 数据 到 达 的 时 候 将 其 返 
回 。 这 种 选择 可 以 放 到 一 个 条 件 化 的 Observable 中 。 


// 伪 代码 
Observable.create(s -> { 
T fromCache = getFromCache(SOME KEY); 
if(fromCache != null) { 
// 同 步 发 布 
s.onNext(fromCache); 
s.onCompleted(); 
} elsef{ 
// 异 步 抓 取 
getDataAsynchronously(SOME_KEY) 
.ONResponse(v -> { 
putInCache(SOME_KEY, v); 
s.onNext(v); 
s.onCompleted(); 
}) 


























四 
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.OnFaiLure(exception -> { 
s.onError(exception); 


]); 


}).subscribe(s -> System.out.printLn(s) ); 


2. 同步 计算 〈 如 操作 符 ) 

保持 同步 的 更 常见 原因 是 通过 操作 符 进行 流 组 合 和 转换 。RxJava 会 使 用 大 量 的 操作 符 API 
来 操作 、 组 合 和 转换 数据 ， 比 如 map()、filter()、take()、flatMap() 和 groupBy()。 大 多 数 
这 样 的 操作 符 是 同步 的 ， 这 意味 着 在 事件 经 过 的 时 候 ， 它 们 会 在 onNext() 中 执行 同步 计算 。 


出 于 性 能 原因 ， 这 些 操作 符 都 是 同步 的 。 以 下 面 的 代码 为 例 。 


Observable<Integer> 0 = Observable.create(s -> { 
s.onNext(1); 
s.onNext(2); 
s.onNext(3); 
s.onCompleted(); 
]); 























o.map(i -> "Number " + i) 
.Subscribe(s -> System.out.println(s)); 


假如 map 操作 符 默 认 是 异步 的 ，(1, 2, 3) 中 的 每 个 数字 都 会 调度 到 一 个 线程 上 ， 在 这 个 线程 
上 将 会 执行 字符 串 连 接 ("Number ”+ i)。 这 是 非常 低 效 的 ， 调 度 、 上 下 文 切换 等 一 般 还 
会 造成 不 确定 的 延迟 。 

这 里 需要 着 重 理解 的 就 是 大 多 数 的 Observable 函数 管道 是 同步 的 (除非 某 个 特定 的 操作 符 
需要 是 异步 的 ， 比 如 timeout 或 observe0n) ， 而 0bservablte 本 身 可 以 是 异步 的 。 这 些 主题 
在 4.9.5 节 和 7.1.3 节 会 深入 介绍 。 


如 下 的 样 例 展现 了 同步 和 异步 的 混合 使 用 。 


Observable.create(s -> { 
。async subscription and data emission ... 














}) 

.doOnNext(i -> System.out.println(Thread.currentThread())) 
.filter(i -> i % 2 == 0) 

.map(i -> "Value " + i + " processed on " + Thread.currentThread()) 
.Subscribe(s -> System.out.println("SOME VALUE =>" + s)); 
System.out.println("Will print BEFORE vaLues are emitted") 


本 例 中 的 Observable 是 异步 的 〈 它 会 在 与 订阅 者 不 同 的 线程 中 发 布 事件 )， 所 以 订阅 是 非 
阻塞 的 ， 最 后 的 printtn 的 输出 将 会 早 于 事件 的 传播 ， 并 先 于 “SOME VALUE 二 ”显示 。 
但 是 ，filter() 和 map() 国 数 是 同步 执行 的 ， 它 们 会 在 调用 发 布 事件 的 线程 中 执行 。 一 般 
来 说 ， 这 是 期 望 的 行为 : 实现 异步 的 管道 (0bservabte 和 组 合 操作 符 )， 让 事件 保持 高 效 
的 同步 计算 。 

因此 ，0bservable 类 型 本 身 支持 同步 和 异步 的 具体 实现 ， 其 设计 本 意 即 是 如 此 。 




















1.3.3 ”并 发 与 并 行 


单个 的 Observable 流 既 不 允许 并 发 ， 也 不 允许 并 行 。 相 反 ， 


来 实现 的 。 
并 行 (parallelism) 指 的 是 任务 同时 执行 ， 


它们 是 通过 组 合 异步 Observable 





通常 会 在 不 同 的 CPU 或 机 器 上 。 而 并 发 











(concurrency) 指 的 是 多 任务 的 组 合 和 交叉 。 
程 )， 它 们 是 通过 “时 间 分 片 ”实现 的 并 发 ， 
时 间 ， 然 后 即便 该 线程 尚未 完成 ， 


也 要 将 CPU 时 间 让 给 其 他 线程 。 











如 果 一 个 CPU 上 面 有 多 个 任务 的 话 (比如 线 
而 不 是 并 行 。 每 个 线程 会 得 到 一 部 分 的 CPU 























根据 定义 ， 并 行 执行 是 并 发 的 ， 但 是 并 发 不 一 





定 是 并 行 的 。 实 际 上 ， 这 意味 着 多 线程 是 并 


发 的 ， 但 是 只 有 这 些 线程 同时 被 调度 到 不 同 的 CPU 上 并 在 其 上 执行 时 ， 才 是 并 行 。 因 此 


通常 我 们 会 讨论 并 发 性 和 如 何 并 发 ， 并 行 则 是 








RxJava 的 Observable 契约 要 求 事件 (onNext()、 
发 发 布 。 换 名 话说 ， 单 个 0bservable 流 必 须 始 终 是 序列 化 和 线程 安全 的 。 
同 的 线程 中 发 布 出 来 ， 只 要 发 布 不 是 并 发 的 即 可 。 这 意味 着 onNext() 没有 交叉 或 同时 执 
如 果 onNext() 依然 还 在 某 个 线程 上 执行 ， 那 么 其 他 的 线程 将 不 能 再 次 调用 它 ( 交 又 )。 





不 
行 。 
下 
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看 的 样 例 展现 了 正确 的 代码 。 


Observable.create(s -> { 
new Thread(() -> { 
s.onNext("one"); 








s.onNext("two"); 
s.onNext("three"); 
s.onNext("four"); 
s.onCompleted(); 
}).start(); 
]); 


这 段 代 码 顺序 地 发 布 数据 ， 所 以 它 符 合 契约 。 
动 线程 ， 而 应 使 用 调度 器 


如 下 的 样 例 展现 了 非法 代码 。 
// 不 要 这 样 做 


Observable.create(s -> { 
// 线 程 A 
new Thread(() -> { 
s.onNext("one"); 
s.onNext("two"); 
}).start(); 


// 线 程 B 

new Thread(() -> { 
s.onNext("three"); 
s.onNext("four"); 

}).start(); 














是 一 种 特定 形式 的 并 发 。 


onError()) 始终 避免 并 
每 个 事件 可 以 从 


onCompleted().、 





(注意 ， 一 般 不 建议 这 样 在 observable 中 局 








， 参 见 4.9 节 中 的 讨论 。) 


// 由 于 线程 竞争 ， 不 需要 发 布 s.onCompleted() 


}); 
// 不 要 这 样 做 

















使 
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这 段 代 码 是 非法 的 ， 因 为 它 的 两 个 线程 能 够 并 发 地 调用 onNext() ， 这 破坏 了 契约 。( 同 时 ， 
它 还 需要 安全 地 等 待 两 个 线程 都 完成 才能 安全 地 调用 onCompLete， 如 前 所 述 ， 这 样 手动 启 
动 线程 很 糟糕 。) 

那么 ， 该 如 何 结合 RxJava 发 挥 并 发 和 并 行 的 优势 呢 ?” 那 就 是 组 合 。 

单个 Observable 流 始 终 是 序列 化 的 ， 但 是 每 个 Observable 可 以 独立 于 其 他 0bservable 来 


进行 操作 ， 因 此 能 够 实现 并 发 /并行 。 这 也 是 merge 和 flatMap 在 RxJava 中 如 此 常用 的 原 
因 所 在 一 一 并 发 地 将 异步 流 组 合 在 一 起 (参见 3.1.2 节 和 3.2.1 节 )。 


如 下 是 编造 的 一 个 例子 ， 展 示 了 在 各 自 线程 中 运行 异步 Observable 以 及 将 其 合并 起 来 的 机 制 。 


Observable<String> a = Observable.create(s -> { 
new Thread(() -> { 
s.onNext("one"); 
s.onNext("two"); 
s.onCompleted(); 
}).start(); 
]); 



































Observable<String> b = Observable.create(s -> { 
new Thread(() -> { 
s.onNext("three"); 
s.onNext("four"); 
s.onCompleted(); 
}).start(); 
]); 


// 并 发 订阅 a 和 b， 并 将 它们 合并 到 第 三 个 序列 化 流 中 


Observable<String> c = Observable.merge(a, b); 
Observable < 将 会 收 到 来 自 a 和 4b 的 条 目 ， 因 为 它们 的 异步 性 ， 将 会 发 生 以 下 三 件 导 
。 one 会 出 现在 two 之 前 。 


。 three 会 出 现在 four 之 前 。 
。 one/two 和 three/four 的 顺序 是 不 确定 的 。 


那么 ， 到 底 为 什么 不 允许 并 发 地 调用 onNext() 呢 ? 


主要 原因 在 于 onNext() 本 意 是 供 人 类 使 用 的 ， 并 发 比较 困难 。 假 如 能 够 并 发 调用 
onNext()， 这 就 意味 着 所 有 Observer 都 需要 为 并 发 调用 进行 防御 性 编码 ， 即 便 本 来 并 不 期 
望 或 想 要 这 样 调 用 。 
第 二 个 原因 在 于 有 些 操作 无 法 实现 并 发 发 布 ， 比 如 scan 和 reduce， 它 们 是 非常 常见 且 重 
要 的 行为 。 像 scan 和 reduce 这 样 的 操作 符 需 要 有 顺序 的 事件 传播 ， 这 样 状态 才能 在 事件 
流 上 累积 ， 这 些 事件 不 能 兼 具 组 合 性 (associative) 和 可 交换 性 (commutative)。 人 允许 并 发 
的 Observable 流 (具有 并 发 的 onNext()) 将 限制 能 够 处 理 的 事件 类 型 ， 并 且 需 要 线程 安全 
的 数据 结构 。 




















二 










































































Java 8 的 Stream 类 型 支持 并 发 发 布 。 这 也 是 java.util.stream.Strean 需要 
reduce 函数 具备 组 合 性 的 原因 ， 它 们 必须 支持 在 并 行 流 上 并 发 调用 。 在 java. 
util.streanm 包 的 文档 中 ， 关 于 并 行 、 排 序 (与 交换 性 相关 )、reduction 操作 
以 及 组 合 性 的 部 分 进一步 阐述 了 相同 Stream 类 型 允许 顺序 发 布 和 并 发 发 布 的 


复杂 性 。 























第 三 个 原因 在 于 同步 开销 会 影响 性 能 ， 因 为 所 有 的 0bserver 和 操作 符 都 需要 是 线程 安全 
的 ， 即 便 大 多 数 情况 下 数据 是 顺序 到 达 的 。 尽 管 JVM 通常 擅长 消除 同步 开销 ， 但 是 并 非 
在 所 有 的 场景 中 都 如 此 (尤其 是 使 用 原子 化 的 非 阻 塞 算 法 时 更 是 如 此 )， 最 终 导 致 顺 序 流 
上 产生 不 必要 的 性 能 开销 。 

除 此 之 外 ， 进 行 一 般 的 细 粒 度 并 行 通常 会 更 慢 。 并 行 一 般 需 要 在 较 粗 的 粒度 上 进行 ， 比 如 
批 处 理工 作 ， 以 弥补 切换 线程 、 调 度 工作 和 重新 组 合 的 开销 。 如 果 在 单个 线程 上 同步 执 
行 ， 并 充分 利用 针对 有 顺序 的 计算 的 内 存 和 CPU 优化 ， 那 么 将 会 高 效 得 多 。 对 于 List 或 
array 来 说 ， 为 批 处 理 并 行 找到 合适 的 默认 做 法 是 很 容易 的 ， 因 为 所 有 的 条 目 都 是 提前 可 
知 的 ， 并 且 能 够 划分 为 批 处 理 (但 是 即便 如 此 ， 通 常 来 讲 在 一 个 CPU 上 处 理 整 个 列表 也 
会 更 快 ， 除 非 列表 非常 庞大 或 者 对 每 个 条 目的 处 理 非常 耗 时 )。 但 是 ， 流 无 法 预先 了 解 工 
作 的 情况 ， 只 能 通过 onNext() 接收 数据 ， 因 此 无 法 自动 对 工作 进行 分 块 。 


实际 上 ， 在 vl 版 本 之 前 ，RxJava 添加 过 一 个 .parallel(Function f) 操作 符 ， 它 的 行为 类 似 
于 java.util.stream.Stream.parallel()， 当 时 认为 这 是 非常 便利 的 。 它 的 实现 方式 并 没有 打 
破 RxJava 的 契约 ， 首 先 将 一 个 Observable 分 割 为 多 个 并 行 执行 的 Observable， 随 后 再 将 它 
们 合并 到 一 起 。 但 是 它 在 该 库 更 新 到 vl 版 本 之 前 被 删除 了 ， 因 为 它 令 人 费解 ， 并 且 总 是 会 
降低 性 能 。 为 事件 流 添加 并 行 计算 通常 都 需要 进行 推理 和 测试 。 也 许 ，ParallelObservable 
能 够 提供 一 些 帮 助 ， 为 此 操作 符 被 限定 在 具备 结合 性 的 子 集中 。 但 是 在 使 用 RxJava 的 时 代 
并 不 值得 尝试 ， 因 为 组 合 使 用 merge 和 ftLatMap 就 是 针对 这 种 用 案 的 有 效 构造 。 


第 3 章 将 会 讲解 如 何 使 用 操作 符 组 合 bbservable， 使 其 能 够 从 并 发 和 并 行 中 受益 。 


1.3.4 延迟 执行 与 立即 执行 

Observable 类 型 是 延迟 执行 的 ， 这 意味 着 在 订阅 它 之 前 ， 它 什么 事情 都 不 会 做 。 这 与 立即 
执行 类 型 有 所 不 同 ， 比 如 Future， 它 在 创建 之 时 就 开始 活跃 工作 了 。 延 迟 执行 允许 组 合 
0bservabLe， 不 会 因为 竞 态 条 件 时 缺乏 缓存 而 丢失 数据 。 在 Future 中 ， 这 并 不 是 什么 问 
题 ， 因 为 单个 值 可 以 缓存 起 来 ， 所 以 如 果 值 在 组 合 之 前 就 已 经 传递 到 了 ， 值 依然 能 够 被 获 
取 。 在 一 个 无 界 的 流 中 ， 需 要 无 界 的 缓冲 提供 同样 的 保证 。 因 此 ，0bservable 是 延迟 执行 
的 ， 只 有 被 订阅 之 后 才 会 启动 ， 所 在 在 数据 开始 流动 之 前 可 以 完成 所 有 组 合 。 

实际 上 ， 这 意味 着 两 件 
订阅 之 前 ， 所 有 的 构造 都 不 会 开始 工作 。 


因为 Observable 延迟 执行 的 特性 ， 创 建 之 后 其 实 它 并 不 会 开启 任何 工作 (请 忽略 分 配 
Observable 对 象 本 身 这 项 “工作 ”)。 它 只 是 定义 在 它 最 终 被 订阅 时 ， 应 该 完成 什么 工作 。 
请 考虑 如 下 定义 的 Observable。 



















































































冉 。 





出 叫 
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Observable<T> someData = 0bservabLe.create(s - 
getDataFromServerWithCallback(args, data - 
s.onNext(data); 
s.onCompleted(); 
]); 
}) 
现在 已 经 存在 someData 引用 ,但 是 getDataFromServerWithCallback 还 没有 执行 。 这 里 所 


发 生 的 就 是 0bservable 包装 器 声明 了 一 组 要 执行 的 工作 ， 也 就 是 0bservable 中 的 函数 。 
订阅 Observable 会 让 任务 开始 执行 。 

someData. subscribe(s -> System.out.printtn(s)); 
这 样 的 话 ， 就 会 延迟 执行 Observable 代表 的 工作 。 
Observable 可 以 重用 。 
因为 Observable 是 延迟 执行 的 ， 也 就 意味 着 一 个 特定 的 实例 可 以 调用 多 次 。 继 续 分 析 前 
的 样 例 ， 这 意味 着 我 们 可 以 这 样 做 : 


someData.subscribe(s -> System.out.printLn("Subscriber 1: " + s)); 
someData.subscribe(s -> System.out.println("Subscriber 2: " + s)); 


现在 有 了 两 个 单独 的 订阅 ， 每 个 都 调用 getDataFromServerWithCallback 并 发 布 事件 。 


延迟 执行 不 同 于 其 他 的 异步 类 型 ， 比 如 Future, 创建 的 Future 代表 了 已 经 开始 的 工作 。Future 
不 能 重用 (订阅 多 次 来 触发 工作 )。 如 果 存 在 对 Future 的 引用 ， 那 么 就 意味 着 工作 已 经 开 
始 执 行 。 前 面 的 示例 代码 展示 了 立即 执行 是 什么 。getDataFromServerWithCallback 就 是 立 
即 执行 的 ， 因 为 在 调用 的 时 候 ， 它 会 马上 执行 。 围 绕 getDataFromServerWithCallback 包装 
一 个 0bservable， 就 能 够 以 延迟 执行 的 形式 使 用 它 。 


在 进行 组 合 的 时 候 ， 延 迟 执行 是 非常 有 用 的 ， 如 下 所 示 。 


someData 
.ONErrorResumeNext(lazyFallback) 
.Subscribe(s -> System.out.println(s)); 


在 这 个 样 例 中 ，LazyFaLLback Observable 代表 了 将 来 可 以 完成 的 工作 。 但 是 这 些 工 作 只 在 
有 人 订阅 的 时 候 才 会 完成 ， 而 我 们 想 要 只 在 someData 失败 的 时 候 才 订阅 它 。 当 然 ， 立 即 执 
行 类 型 可 以 通过 使 用 函数 调用 实现 延迟 执行 (比如 getDataAsFutureA() ) 。 


虽然 延迟 执行 和 立即 执行 J 但 是 RxJava 中 的 0bservable 是 延迟 执行 的 。 因 此 
Observable 在 被 订阅 之 前 ， 它 是 不 会 做 任何 事情 的 。 


4.3 节 还 会 详细 讨论 这 个 话题 。 


1.3.5 ”双重 性 

Rx 的 Observable 是 一 个 异步 的 “双重 ”(dual) Iterable。 所 请“ 双重 ”， 指 的 是 0bservable 
提供 了 Iterable 的 所 有 功能 ， 但 数据 方向 相反 : 它 推送 数据 ， 而 不 是 拉 取 数据 。 表 1-1 展 
现 了 提供 推送 和 拉 取 功能 的 类 型 。 
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表 1-1: 提供 推送 和 拉 取 功能 的 类 型 











拉 取 (Iterable) 推送 (0bservable) 
T next() onNext(T) 

抛 出 异常 onError(ThrowabtLe) 
返回 onCompleted() 





从 表 1-1 可 以 看 出 ， 数 据 不 是 由 消费 者 通过 next() 拉 取 的 ， 而 是 由 生产 者 通过 onNext(T) 
推送 的 。 成 功 的 终止 要 通过 onCompleted() 回调 进行 标记 ， 而 不 是 阻塞 线程 直到 遍历 完 所 
有 的 条 目 。 在 出 现 错误 时 ， 也 不 是 在 调用 栈 上 抛 出 异常 ， 而 是 将 错误 以 事件 的 形式 发 布 到 
onError(Throwable) 回调 上 。 


它 的 行为 具有 双重 性 意味 着 通过 Iterable 和 Iterator 实现 的 同步 拉 取 ， 都 能 通过 0bservable 
和 Observer 以 异步 推送 的 方式 来 实现 。 这 样 的 话 ， 相 同 的 编程 模型 可 以 应 用 于 这 两 者 。 


例如 ，Java 8 中 的 Iterable 可 以 通过 java.util.stream.Streanm 类 型 实现 函数 组 合 ， 如 下 所 示 。 


// 将 包含 75 个 字符 串 的 IterabLe 作 为 Stream 
getDataFromLocalMemorySynchronously() 
.Skip(10) 
.Limit(5) 
.map(s -> s + "_transformed") 
.forEach(System.out: :println) 


此 例 将 会 从 getDataFromLocalMemorySynchronously() 中 检索 75 个 字符 串 ， 并 且 只 获取 
顺序 从 11 到 15 的 字符 串 ， 忽 略 其 他 字符 串 ， 然 后 转换 获取 到 的 字符 串 并 将 其 打印 出 来 。 
(3.4 节 将 会 介绍 更 多 的 操作 符 ， 如 take、skip 和 Limit。) 


RxJava 0bservable 的 使 用 方式 与 之 相同 。 


// 会 发 布 75 个 字符 串 的 Observable 
getDataFromNetworkAsynchronously() 
.Skip(10) 
.take(5) 
.map(s -> s + "_transformed") 
.Subscribe(System.out::println) 


此 例 将 会 接收 5 个 字符 串 (发 布 了 15 个 字符 串 ， 但 是 前 10 个 丢弃 了 )， 然 后 取消 订阅 
(忽略 或 停止 要 发 布 的 其 他 字符 串 )。 它 会 进行 转换 并 将 字符 串 打印 出 来 ， 与 前 面 的 
IterabLe/Streanm 样 例 类 似 。 
换 句 话说 ，Rx 中 的 0bservable 允许 通过 推送 的 方式 对 异步 数据 进行 编程 ， 就 像 Streams 
围绕 Iterable 和 List 以 同步 拉 取 的 方式 进行 编程 一 样 。 


1.3.6 ”基数 


Observable 支持 异步 推送 多 个 值 。 这 很 好 地 匹配 表 1-2 中 的 右 下 角 ， 上 共有 异步 双重 性 的 
Iterable (或 Stream、List、Enumerable 等 ) 以 及 多 值 版 本 的 Future。 
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表 1-2: 基数 





人 乡 从 
同步 ”TgetData() Iterable<T> getData() 
异步 Future<T> getData() Observable<T> getData() 


注意 ， 这 一 节 指 的 是 通用 的 Future， 它 使 用 Future.onSuccess(caLLback) 语法 来 代表 它 的 行 
为 。 存 在 各 种 实现 ， 比 如 CompletableFuture、ListenableFuture 或 Scala 的 Future。 但 是 不 
管 使 用 哪 一 个 实现 ， 切 记 不 要 使 用 java.util.Future， 因 为 它 在 获取 值 的 时 候 需 要 阻塞 。 
那么 ， 为 什么 Observable 比 单纯 的 Future 更 有 价值 呢 ? 最 明显 的 原因 是 0bservable 能 够 
处 理 一 个 事件 流 或 多 值 响 应 。 而 另外 一 个 不 那么 显而易见 的 原因 在 于 ， 它 能 够 对 多 个 具有 
单个 值 的 响应 进行 组 合 。 下 面 依次 来 了 解 一 下 。 

1. 事件 流 
事件 流 非常 简单 。 随 着 时 间 的 推移 ， 生 产 者 将 事件 推送 给 消费 者 ， 如 下 所 示 。 

// 生 产 者 


Observable<Event> mouseEvents = ...; 
























































// 消 费 者 

mouseEvents.subscribe(e -> doSomethingWithEvent(e)); 
如 果 使 用 Future 的 话 ， 它 将 无 法 很 好 地 运行 。 

// 生 产 者 


Future<Event> mouseEvents = ...; 


// 消 费 者 

mouseEvents.onSuccess(e -> doSomethingWithEvent(e)); 
onSuccess 回调 可 能 会 收 到 “最 后 的 事件 ”>， 但 是 有 些 问 题 依 然 存在 : 消费 者 现在 是 否 
需要 轮 询 ? 生产 者 是 否 要 对 它们 进行 排队 ? 或 者 ， 在 每 次 获取 之 间 ， 它 们 是 否 会 丢失 ? 
Observable 在 这 里 肯定 是 有 帮助 的 。 而 在 没有 0bservable 的 情况 下 ， 回 调 方法 要 比 将 其 建 
模 为 Future 更 好 。 
2. 多 个 值 
多 值 响应 是 Observable 的 另 一 个 用 武之 地 。 一 般 来 讲 ， 任 何 使 用 Litst、Iterablte 或 
Strean 的 地 方 ， 都 可 以 使 用 0bservable 来 替换 。 


// 生 产 者 


Observable<Friend> friends = ... 

















// 消 费 者 


friends.subscribe(friend -> sayHello(friend)); 
现在 ， 也 可 以 和 Future 协作 使 用 ， 如 下 所 示 。 
// 生 产 者 


Future<List<Friend>> friends = ... 


// 消 费 者 
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friends.onSuccess(listOfFriends -> { 
listofFriends.forEach(friend -> sayHello(friend)); 
]); 


那么 ， 为 什么 要 使 用 Observable<Friend> 方式 呢 ? 


如 果 返 回 的 数据 列表 比较 小 的 话 ， 这 可 能 对 性 能 并 没有 太 大 的 影响 ， 选 择 哪 种 方式 完全 取 
决 于 个 人 喜好 。 但 是 ， 如 果 列 表 非 党 大， 或 者 远程 数据 源 必须 从 不 同 的 位 置 获 取 列表 的 不 
同 部 分 ， 那 么 Observable<Friend> 方式 在 性 能 和 延迟 性 方面 会 有 更 好 的 表现 。 

最 让 人 信服 的 原因 就 是 ， 可 以 在 接收 到 条 目的 时 候 就 进行 处 理 ， 而 不 必 等 到 整个 集合 的 内 
容 全 部 抵达 再 进行 处 理 。 如 果 后 端的 各 种 网 络 延迟 会 对 每 个 条 目 造成 不 同 影响 的 话 ， 这 一 
点 就 更 为 明显 ， 因 为 长 尾 延迟 (比如 在 面向 服务 的 架构 或 微服 务 架构 中 ) 和 共享 数据 存 
储 ， 这 种 情况 确实 很 常见 。 如 果 要 等 待 整个 集合 的 话 ， 消 费 者 将 会 经 历 完成 该 集合 聚合 需 
要 的 最 长 延迟 。 如 果 条 目 是 以 0bservable 流 的 形式 返回 ， 那 么 消费 者 能 够 立即 接收 它们 ， 
“第 一 个 条 目的 耗 时 ”可 能 会 明显 低 于 最 后 一 个 和 最 慢 条 目的 耗 时 。 要 使 这 种 方式 能 够 正 
常 运行 ， 必 须要 牺牲 流 的 顺序 ， 这 样 才能 让 服务 器 按照 收 到 的 顺序 发 布 条 目 。 如 果 顺 序 对 
用 户 来 说 非常 重要 ， 那 么 在 条 目 数据 或 元 数据 中 可 以 包含 一 个 排序 或 位 置信 息 ， 这 样 客户 
端 可 以 按 需 对 条 目 进行 排序 和 定位 。 

此 外 ， 这 种 方式 还 能 按 每 个 条 目的 需求 分 配 内 存 ， 而 不 必 为 整个 集合 分 配 和 收集 内 存 。 

3. 组 合 

在 组 合 单 值 响 应 ， 比 如 组 合 来 自 Future 的 响应 时 ， 多 值 的 Observable 类 型 也 是 非常 有 用 的 。 
在 合并 多 个 Future 时 ， 需 要 发 布 另外 一 个 带 有 单个 值 的 Future， 如 下 所 示 。 


getDataAsFuture(1); 
getDataAsFuture(2); 











































































































CompletableFuture<String> f1 
CompletableFuture<String> f2 


CompletableFuture<String> f3 = f1.thenCombine(f2, (x, y) -> { 
return x+y; 


}); 


这 可 能 就 是 想 要 的 效果 ， 实 际 上 也 可 以 通过 RxJava 的 0bservable.zip 来 实现 (3.2.2 节 将 
会 介绍 更 多 这 方面 的 知识 )。 


Observable<String> o1 = getDataAsObservable(1); 
Observable<String> 02 = getDataAsObservabLe(2); 


Observable<String> 03 = Observable.zip(o1, 02, (x, y) -> { 
return x+y; 


}); 


但 是 ， 这 意味 着 在 发 布 内 容 之 前 必须 要 等 待 ， 直 到 所 有 Future 完成 。 通 常 ， 更 好 的 方式 
是 在 每 个 任务 完成 的 时 候 就 发 布 Future 返回 的 值 。 本 例 使 用 0bservable.merge (或 相关 的 
flatMap) 会 是 更 好 的 方案 。 它 允许 将 结果 (即便 每 个 结果 都 是 发 布 一 个 值 的 Observable) 
组 合 为 由 值 组 成 的 流 ， 这 些 值 在 它们 就 绪 的 时 候 就 会 发 布 出 来 。 

Observable<String> o1 = getDataAsObservable(1); 

Observable<String> 02 = getDataAsObservabLe(2); 
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// 现 在 ，o3 是 o1 和 o2 组 成 的 流 ， 会 立即 发 布 条 目 ， 无 须 等 待 
Observable<String> 03 = Observable.merge(o1, 02); 





4. Single 

现在 来 看 ， 尽 管 Rx 0bservable 在 处 理 多 值 流 的 时 候 非 常 棒 ， 但 简洁 的 单 值 表 示 非 常 适 
合 API 的 设计 和 使 用 。 此 外 ， 基 本 的 请 求 /响应 行为 在 应 用 程序 中 非常 普遍 。 基 于 此 ， 
RxJava 提供 了 一 个 Single 类 型 ， 它 与 Future 是 对 等 的 ， 只 不 过 它 是 延迟 执行 的 。 可 以 将 
Single 视 为 具备 两 个 特殊 优点 的 Future: 首先 ， 它 是 延迟 执行 的 ， 所 以 它 可 以 被 多 次 订阅 
并 且 易 于 组 合 ， 其 次 ， 它 适 配 RxJava 的 API， 所 以 它 能 够 很 容易 地 与 Observable 交互 。 


例如 ， 考 虑 如 下 的 访问 器 。 


public static Single<String> getDataA() { 
return Single.<String> create(o -> { 
o.onSuccess("DataA"); 
}).subscribeOn(Schedulers.io()); 




































































public static Single<String> getDataB() { 
return Single.just("DataB") 
.SubscribeOn(Schedulers.io()); 


} 
它们 还 可 以 按照 下 面 的 方式 使 用 和 组 合 。 
// 将 a 和 b 合 并 到 由 两 个 值 组 成 的 0bservable 流 中 
Observable<String> a_merge_b = getDataA().mergeWith(getDataB()); 
请 注意 这 两 个 single 是 如 何 合并 到 一 个 Observable 中 的 。 这 样 发 布 出 的 数据 可 能 是 [A, B]， 
也 可 能 是 [B, A]， 具 体 取 决 于 哪个 先 完成 。 
回 到 前 面 的 例子 ， 现 在 可 以 使 用 single 禁 换 0bservable 来 表示 数据 的 获取 ， 但 是 要 将 它 
们 合并 到 一 个 值 的 流 。 


//Observable<String> ol1 
//0bservabLe<String> 02 
































= getDataAsObservable(1); 
= getDataAsObservabLe(2); 
Single<String> s1 
Single<String> s2 


getDataAsSingle(1); 
getDataAsSingle(2); 


// 现 在 ，o3 是 s1 和 s2 组 成 的 流 ， 会 立即 发 布 条 目 ， 无 须 等 待 
Observable<String> 03 = Single.merge(s1, s2); 

使 用 single 来 代替 0bservable 表示 “单个 值 的 流 ” 能 够 简化 使 用 ， 因 为 开发 人 员 必 须要 

考虑 single 只 能 具有 如 下 行为 中 的 一 种 。 

。 响应 错误 。 

。 永远 不 响应 。 

。 响应 成 功 。 

与 之 相对 ， 消 费 者 在 使 用 0bservable 的 时 候 ， 必 须要 考虑 一 些 其 他 的 状态 。 


。 响应 错误 。 
。 永远 不 响应 。 
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向 应 成 功 ， 没 有 数据 并 终止 。 

向 应 成 功 ， 有 单个 数据 值 并 终止 。 

向 应 成 功 ， 有 多 个 数据 值 并 终止 。 

向 应 成 功 ， 有 一 个 或 多 个 值 ， 并 且 永 远 不 终止 (等待 更 多 数据 )。 

使 用 single， 消 费 该 API 的 思维 模型 会 更 加 简单 。 只 有 在 组 合 到 0bservable 中 之 后 ， 开 
发 人 员 才 必须 考虑 其 他 状态 。 这 通常 是 它 更 适用 的 地 方 ， 因 为 通常 由 开发 人 员 控 制 代 码 
而 数据 API 通常 来 自 第 三 方 。 

5.5 节 将 会 介绍 Singte 的 更 多 知识 。 


5. Completable 

除了 Single 之 外 ，RxJava 还 有 一 个 Completable 类 型 。 它 解决 了 没有 返回 类 型 ， 只 需要 
表示 成 功 或 失败 的 常见 场景 。 通 常会 使 用 0bservable<Void> 或 SingLe<votid>， 但 这 有 些 奉 
强 ， 因 此 才 诞 生 了 Completable， 如 下 所 示 。 


Completable c = writeToDatabase("data"); 


这 种 场景 在 进行 异步 写 入 的 时 候 很 常见 ， 此 时 不 需要 返回 值 ， 只 需要 通知 成 功 或 失败 即 
可 。 前 面 使 用 Completable 的 代码 类 似 于 : 


Observable<Void> c = writeToDatabase("data"); 
Completable 本 身 是 两 个 回调 的 抽象 ， 即 成 功 和 人 失败， 如 下 所 示 。 


static Completable writeToDatabase(Object data) { 
return Completable.create(s -> { 
doAsyncWrite(data, 
// 成 功 完 成 的 回调 
() -> s.onCompleted(), 
// 抛 出 Throwable 而 失败 的 回调 


error -> s.onError(error)); 

























































































}): 
} 


6. 零 到 无 穷 
Observable 能 够 支持 的 基数 从 零 到 无 穷 (2.4.2 节 还 会 进一步 探讨 ) 。 但 是 为 了 简单 和 清晰 ， 
single 是 “只 有 一 个 条 目的 0bservabLe”， 而 Completable 则 是 “没有 条 目的 Observable”。 


加 上 这 些 新 引入 的 类 型 后 ， 如 表 1-3 所 示 。 
表 1-3: 0bservable 能 够 支持 的 基数 从 零 到 无 穷 











零 个 = ST 
同步 ”void doSomething() T getData() Iterable<T> getData() 
异步 Completable doSomething() Single<T> getData() Observable<T> getData() 








1.4 ”阻塞 |/O 与 非 阻 塞 |/O 


到 目前 为 止 ， 关 于 反应 式 - 函数 式 风格 编程 的 讨论 主要 在 于 提供 一 个 异步 回调 的 抽象 机 
制 ， 以 允许 实现 更 易 管理 的 组 合 ， 显 然 ， 如 果 将 不 相关 的 网 络 请 求 并 发 所 和 了 而 不 是 顺序 执 
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行 的 话 ， 将 会 改善 用 户 的 延迟 体验 ， 这 是 采用 异步 和 需要 组 合 的 原因 。 

但 是 ， 有 性 能 方面 的 因素 促使 我 们 采用 反应 式 的 方式 (不管 是 命令 式 的 还 是 函数 式 的 ) 来 
执行 VO 吗 ? 采用 非 阻 塞 TO 会 有 什么 好 处 吗 ? 或 者 说 阻塞 IO 线程 以 等 待 单个 网 络 请 求 
难道 不 可 以 吗 ? 我 在 Netflix 参与 的 性 能 测试 表明 ， 与 每 个 请 求 对 应 一 个 线程 的 阻塞 IO 相 
比 ， 采 用 非 阻塞 VO 和 事件 循环 会 带 来 客观 且 可 测量 的 性 能 收益 。 这 一 节 分 析 了 具体 原因 ， 
并 提供 了 帮助 你 做 出 决定 的 数据 。 


























追寻 答案 的 历程 

在 使 用 RxJava 一 段 时 间 之 后 ， 我 想 知道 阻塞 IJO 和 非 阻塞 JO (具体 来 讲 ， 也 就 是 每 个 
请 求 对 应 一 个 线程 与 事件 循环 ) 的 对 比 结果 ， 但 是 我 发 现 很 难得 到 明确 的 答案 。 实 际 上 ， 
在 研究 这 个 话题 的 过 程 中 ， 我 发 现 了 自 相 矛盾 的 答案 、 传 言 、 理 论 、 观 点 和 困惑 。 最 终 ， 
我 得 出 了 结论 ， 那 就 是 在 理论 上 ， 所 有 不 同方 式 (比如 纤 程 、 事 件 循环 、 线 程 和 CSP) 
的 性 能 〈 吞 吐 量 和 延迟 ) 应 该 相同 ， 因 为 最 终 所 有 的 方式 使 用 的 是 相同 的 CPU 资源 。 但 
是 ， 在 实践 中 ， 具 体 实现 是 由 数据 结构 和 算法 组 成 的 ， 而 且 必 须要 处 理 硬件 的 具体 状况 ， 
因此 ， 首 先 要 “理解 ”硬件 是 如 何 工作 的 ， 然 后 掌握 操作 系统 和 运行 时 的 实现 方式 。 


我 本 人 无 法 回答 这 些 问题 ， 但 是 我 很 幸运 ， 能 够 和 Brendan Gregg 一 起 工作 。 之 无疑 
间 ， 在 这 方面 他 有 着 丰富 的 经 验 。 我 们 和 Nitesh Kant 一 起 工作 了 数 月 ， 测 试 Tomcat 
和 基于 Netty 的 应 用 程序 。 


我 们 特意 选择 了 “真实 ”的 代码 ， 如 Tomcat 和 Netty， 因 为 它 是 和 生产 系统 的 选择 紧 





密 相 关 的 (我们 已 经 使 用 了 Tomcat， 并 且 当 时 正在 研究 使 用 Netty) 。 它 们 在 架构 方面 
的 主要 差异 在 于 ， 每 个 请 求 对 应 一 个 线程 还 是 事件 循环 。 


你 可 以 在 GitHub 的 Netflix-Skunkworks/WsPerfLab 仓库 中 看 到 这 项 研究 的 细节 ， 另 
外 还 有 用 于 测试 的 代码 。 你 还 可 以 在 SpeakerDeck 上 查阅 一 篇 概述 和 演讲 ， 题 目 为 


Applying Reactive Programmiing with RxJava, 








正如 “追寻 答案 的 历程 ”中 提 到 的 ,在 Linux 上 基于 Tomcat 和 Netty 对 阻塞 WO 和 非 阻 塞 
IO 的 性 能 进行 了 对 比 测试 。 这 种 类 型 的 测试 通常 会 有 一 定 的 争议 性 ， 并 且 难 以 得 到 非常 
准确 的 结果 ， 所 以 这 项 测试 仅 适用 于 如 下 场景 。 



































2015/2016 年 左右 的 典型 Linux 系统 的 行为 。 

Java 8 (OpenJDK 和 Oracle)。 

典型 生产 环境 中 的 未 经 修改 的 Tomcat 和 Netty。 

具有 代表 性 的 Web 服务 请 求 / 响应 负载 ， 涉 及 多 个 其 他 Web 服务 的 组 合 。 





基于 这 样 的 环境 ， 得 出 了 如 下 的 结论 。 





Netty 代码 要 比 Tomcat 代码 更 高 效 ， 并 且 每 个 请 求 消耗 更 少 的 CPU。 

Netty 的 事件 循环 架构 会 减少 高 负载 情况 下 的 线程 迁移 ， 这 会 提升 CPU 缓存 的 热度 和 内 
存 的 本 地 化 ， 提 升 CPU 每 个 周期 的 指令 〈Instructions-per-Cycle，IPC) 数量 ， 从 而 降低 
每 个 请 求 的 CPU 周期 消耗 。 
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。 因为 Tomcat 的 线程 池 架 构 ， 在 面临 负载 时 Tomcat 会 有 更 高 的 延迟 ， 这 涉及 服务 在 负载 
情况 下 的 线程 地 锁 (以 及 锁 竞 争 ) 和 线程 迁移 。 


图 1-1 阐述 了 这 两 种 架构 的 差异 。 











一 RxNetty 一 Tomcat 


1600000 





1200000 









随 着 负载 的 增加 ， 会 产生 

更 少 的 迁移 ， 借 助 事件 循 
全 架构 能 够 增加 每 个 请 求 
的 IPC 和 CPU 利用 率 




















800000 





在 低 负载 时 ， 
两 者 类 似 


400000 








0 
50 100 150 200 250 300 350 400 450 500 550 600 650 700 750 800 850 900 950 100010501100 


并 发 客户 端 











图 1-1 


请 注意 在 负载 增加 时 这 两 条 线 的 差异 ， 它 们 指 的 是 线程 的 迁移 。 在 这 个 过 程 中 ， 我 发 现 最 

意思 的 一 件 事 就 是 ，Netty 在 面临 负载 时 会 更 加 高 效 ， 线 程 会 变 得 更 加 “火热 ”并 会 固 
定 到 一 个 CPU 核心 上 。 而 Tomcat 则 无 法 获得 这 种 收益 ， 因 为 每 个 请 求 都 有 一 个 单独 的 线 
程 ， 而 且 因 为 要 为 每 个 请 求 调度 线程 ， 所 以 会 导致 更 高 的 线程 迁移 。 


如 图 1-2 和 图 1-3 所 示 ， 随 着 负载 的 增加 ，Netty 的 CPU 消耗 依然 近乎 平稳 ， 负 载 达到 最 
大 的 时 候 ， 性 能 实际 上 还 有 轻微 的 提升 。 与 之 相反 ，Tomcat 的 效率 会 出 现下 降 。 














每 个 请 求 的 CPU 消耗 
一 RxNetty 一 Tomcat 


0.675ms a 


0.45ms 


。 对 于 每 个 请 求 ，Netty 的 CPU 消耗 更 低 
0.225ms 。 随 着 负载 增加 ，Netty 更 快 ， 而 Tomcat 则 变 得 更 慢 





Oms 
50 100 150 200 250 300 350 400 450 500 550 600 650 700 750 800 850 900 950 100010501100 


并 发 客户 端 














图 1-2 
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每 个 周期 的 CPU 指令 数 
一 RxNetty 一 Tomcat 

0.7ipc 
Dadipe 0 
0.35i 

四 随 着 负载 的 增加 ， 
Netty 每 个 周期 的 指令 
0.175ipc 数 随 之 增加 
Pa0 100 150 200 250 300 350 400 450 500 550 600 650 700 750 800 850 900 950 100010501100 
并 发 客户 端 
1-3 
对 延迟 和 吞吐 量 的 影响 如 图 1-4 所 示 。 
平均 延迟 
一 RxNetty 一 Tomcat 
280ms 
210ms 
140ms 
理论 最 佳 的 测试 场景 是 154 毫 秒 
70ms 
Om 





1S 
50 100 150 200 250 300 350 400 450 500 550 600 650 700 750 800 850 900 950 100010501100 


并 发 客户 端 














图 1-4 











平均 值 并 不 是 非常 有 价值 (相对 于 百 分 位 )， 不 过 从 图 1-4 可 以 看 出 ， 在 负载 很 低 的 时 候 ， 
它们 具有 类 似 的 延迟 ， 但 是 随 着 负载 的 增加 ， 差 异 变 得 更 加 明显 。 随 着 负载 的 增加 ，Netty 
能 够 更 好 地 利用 机 器 的 资源 ， 对 延迟 的 影响 更 小 。 


1-5 展现 了 异常 情况 如 何 影响 用 户 和 系统 资源 。Netty 能 够 更 优雅 地 处 理 负载 ， 避 免 出 现 
最 糟糕 的 情况 。 























最 大 延迟 





一 RxNetty 一 Tomcat 
3000ms 
2250ms 本 
Tomcat 的 延迟 降级 


要 比 Netty 严 重 得 多 





1500ms 


750ms 


Oms 
50 100 150 200 250 300 350 400 450 500 550 600 650 700 750 800 850 900 950 100010501100 




















并 发 客户 端 
图 1-5 
图 1-6 展现 了 吞吐 量 。 
吞吐 量 
一 RxNetty 一 Tomcat 

5000rps 

3750rps 

2500rps 






1250rps 


"Netty 能 够 实现 更 高 的 否 吐 量 
"这 在 很 大 程度 上 归功 于 每 个 请 求 消耗 的 CPU 更 低 





Orps 
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并 发 客户 端 











图 1-6 


可 以 看 到 Netty 方式 有 两 个 突出 的 优点 。 首 先 ， 延 迟 和 吞吐 量 方面 的 结果 更 好 ， 意 味 着 更 
好 的 用 户 体验 和 更 低 的 基础 设施 成 本 。 其 次 ， 事 件 循 环 架 构 在 负载 情况 下 更 加 可 靠 。 负 载 
增加 时 ， 它 并 不 会 直接 失败 ， 反 而 会 将 机 器 的 资源 发 挥 到 极限 ， 并 且 能 够 更 加 优雅 地 进行 
处 理 。 对 于 大 规模 生产 系统 来 说 ， 这 非常 有 吸引 力 ， 因 为 这 种 系统 需要 处 理 预料 之 外 的 流 

















量 碳 升 ， 并 保持 系统 的 响应 性 。 





使 用 RxJava 实 现 反应 式 编程 
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我 还 发 现 事 件 循 环 架 构 更 易于 运 维 。 为 了 获取 最 优 的 性 能 ， 它 并 不 需要 额外 的 调 优 , 而 每 
个 请 求 对 应 一 个 线程 的 架构 通常 需要 根据 负载 调整 线程 池 的 大 小 (以 及 相关 的 垃圾 收集 )。 

这 并 不 是 针对 该 话题 的 详尽 研究 ， 但 是 这 个 实验 和 结果 数据 是 借助 非 阻塞 IO 和 事件 循环 
实现 “反应 式 ” 架 构 的 有 力 证 据 。 换 名 话说 ， 在 2015/2016 年 的 硬件 、Linux 内 核 和 JVM 


上 ， 
5.1. 


1. 





























通过 事件 循环 进行 非 阻塞 IO 确实 有 好 处 。 
2 而 将 会 进一步 探讨 Netty 和 RxJava。 


5 反应 式 抽 和 象 


实际 上 ，RxJava 类 型 和 操作 符 仅 仅 是 对 命令 式 回 调 的 抽象 。 但 是 ， 这 种 抽象 完全 改变 了 代 
码 风 格 ， 并 且 提 供 了 非常 强大 的 工具 来 实现 异步 和 非 阻塞 编程 。 需 要 付出 一 定 的 努力 才能 
掌握 它 ， 并 且 需 要 转换 思维 方式 才能 熟悉 函数 组 合 和 流 式 思考 。 但 是 在 掌握 之 后 ， 它 可 以 
作为 面向 对 象 和 命令 式 编程 风格 之 外 的 一 个 非常 有 效 的 工具 。 


本 





的 其 余部 分 将 会 介绍 RxJava 运行 和 使 用 的 细节 。 第 2 章 将 阐述 0bservable 是 如 何 产 





生 的 ， 以 及 如 何 使 用 它们 。 第 3 章 会 讲解 一 些 声明 式 且 功能 强大 的 转换 。 





注 1: 


当 事 件 循 环 的 数量 是 内 核 数量 的 1 倍 、1.5 倍 或 2 倍 时 ， 这 一 点 无 可 和 争辩。 我 至 今 未 发 现 这 些 值 的 明 
显 差异 ， 通 常 默 认为 1 倍 。 
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托 马 什 : 努 尔 凯 维 茨 〈Tomasz Nurkiewicz) 


本 章 将 介绍 Reactive Extensions 和 RxJava 的 相关 核心 概念 。 通 过 这 一 章 的 学 习 ， 你 将 会 非 
常熟 悉 0bservabLe<T>、0bserver<T> 和 Subscriber<T>， 并 且 学 会 一 些 实用 的 工具 方法 ， 即 
操作 符 (operator)。0bservable 是 RxJava 的 核心 API， 所 以 一 定 要 理解 它 是 如 何 工作 的 ， 
以 及 它 代表 了 什么 。 在 本 章 中 ， 你 将 会 学 习 0bservable 到 底 是 什么 ， 如 何 创 建 它 ， 以 及 如 
何 与 之 交互 。 这 些 知识 对 于 按照 习惯 用 法 提供 和 使 用 基于 RxJava 的 反应 式 API 至 关 重 要 。 
设计 RxJava 是 为 了 缓解 异步 和 事件 驱动 编程 的 痛苦 ， 但 是 为 了 更 好 地 使 用 它 ， 必 须 理解 
一 些 核 心 的 原则 和 语义 。 和 掌握 了 0bservable 如 何 与 客户 端 代码 协作 之 后 ， 你 就 会 发 觉 自己 
的 编码 功力 大 有 长 进 。 阅 读 完 本 章 ， 你 将 能 够 创建 简单 的 数据 流 ， 并 且 能 以 非常 有 趣 的 方 
式 对 它们 进行 联结 和 组 合 。 


2.1 剖析 rx.0bservabltLe 


rx.0bservable<T> 代表 了 一 个 流 形式 的 值 序列 ， 这 一 抽象 形式 我 们 会 一 直 使 用 。 因 为 这 些 
值 通常 会 在 很 长 一 段 时 间 内 出 现 ， 所 以 我 们 一 般 倾向 于 将 Observable 想象 为 一 个 事件 流 。 
如 果 你 看 看 周围 ， 就 会 发 现 很 多 流 的 例子 。 


















































用 户 界 面 事件 。 
网 络 上 的 字 市 传输 。 


。 在 线 商 店 的 新 订单 。 
。 社交 网 站 的 帖子 。 


如 有 果 想 将 Observable<T> 与 你 更 熟悉 的 事物 进行 类 比 ， 那 么 Iterable<T> 可 能 是 最 接近 的 
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抽象 形式 。 就 像 Iterable<T> 产生 的 Iterator<T> 一 样 ，0bservable<T> 也 可 以 有 零 到 无 
穷 个 类 型 为 T 的 值 。Iterator 能 够 非常 有 效 地 生成 无 穷 序 列 ， 例 如 ， 所 有 的 自然 数 ， 如 
下 所 示 。 


class NaturalNumbersIterator implements Iterator<BigInteger> { 





private BigInteger current = BigInteger .ZERO; 


public boolean hasNext() { 
return true; 


} 


@Override 

public BigInteger next() { 
current = current.add(BigInteger .ONE); 
return current; 


} 

另外 一 个 相似 之 处 就 是 Iterator 自身 可 以 给 客户 端 发 送信 号 ， 表 明 它 没有 更 多 的 条 目 要 生成 
了 ( 稍 后 将 会 详细 介绍 )。 但 是 ， 它 们 的 相似 性 仅 限于 此 。0bservable 本 质 上 是 基于 推送 的 ， 
这 意味 着 由 它 决定 何 时 生成 值 。 而 Iterator 则 会 一 直 处 于 空闲 状态 ， 直 到 有 人 调用 next() 条 
目 。 传 统 上 来 讲 ，0bservable 不 可 能 实现 这 种 行为 一 一 在 某 个 时 间 点 ， 客 户 端 代码 可 以 订阅 
一 个 Observable， 当 0bservable 感觉 应 该 发 布 一 个 值 的 上 时候， 订阅 者 就 会 得 到 通知 。 至 于 发 
布 值 的 时 间 ， 可 能 是 立即 执行 ， 也 可 能 是 永远 不 执行 。6.2 节 会 讨论 “ 回 压 ”(backpressure)。 
借助 这 种 机 制 ，subscriber 能 够 在 特定 的 场景 下 控制 Observable 发 布 值 的 节奏 。 

同样 ，0bservablte 能 够 产生 任意 数量 的 事件 。 显 然 ， 这 与 经 典 的 观察 者 (observer) 模 


式 非常 类 似 ， 该 模式 也 被 称 为 发 布 - 订阅 模式 。 如 果 你 想 了 解 该 模式 的 更 多 信息 ， 请 阅 
读 Erich Gamma 和 Richard Helm 合 著 的 《设计 模式 : 可 复 用 面向 对 象 软件 的 基础 》 但 
是 ， 就 像 Iterator 不 一 定 要 由 底层 的 集合 作为 支撑 一 样 (参见 NaturalNumbersIterator)， 


Observable 也 不 一 定 需要 代表 事件 流 。 接 下 来 看 一 些 0bservable 的 样 例 。 
DD Observable<Tweet> tweets 
tweets 可 能 是 最 明显 的 事件 流 的 样 例 了 。 我 们 立刻 明白 ， 任 何 社交 媒体 网 站 的 状态 都 
在 不 停 地 更 新 ， 所 以 它们 当然 能 够 以 事件 流 的 形式 来 表示 。 不 同 于 Iterator ， 我 们 不 能 
手动 拉 取 需要 的 数据 ，0bservable 必须 在 数据 到 达 的 时 候 将 其 推送 给 我 们 。 
DD Observable<Double> temperature 
temperature 0bservable 与 tweets 非常 类 似 ， 它 会 生成 某 个 设备 的 温度 值 并 将 其 推送 给 
订阅 者 。tweets 和 temperature 0bservabte 都 是 由 未 来 事件 组 成 的 无 穷 流 的 样 例 。 


口 Observable<Customer> customers 
0bservable<Customer> 代表 的 内 容 取决 于 上 下 文 。 它 最 可 能 返回 的 是 从 数据 库 查询 得 到 
的 一 个 客户 列表 ， 它 可 能 是 零 个 、 多 个 甚至 上 千 个 可 能 延迟 加 载 的 项 。 这 个 0bservable 
还 可 能 代表 要 记录 到 系统 中 的 Customer 日 志 流 。 不 管 0bservable<Customer> 如 何 实现 ， 
客户 端 编程 模型 不 会 发 生变 化 。 




















































































































口 Observable<HttpResponse> response 
与 上 面 介 绍 的 不 同 ，0bservable<HttpResponse> 很 可 能 在 终止 的 时 候 只 生成 一 个 事件 
( 值 )。 这 个 值 会 在 未 来 某 个 时 间 点 出 现 ， 并 且 会 被 推送 至 客户 端 代码 。 要 阅读 这 个 响 
应 ， 我 们 必须 进行 订阅 。 

口 Observable<Void> completionCallback 
最 后 ， 是 看 上 去 有 些 诡异 的 Observable<Void>。 从 技术 上 来 讲 ，0bservable 可 以 不 发 布 

任何 条 目 就 终止 。 在 这 种 情况 下 ， 我 们 并 不 关心 Observable 推送 的 实际 类 型 ， 因 为 它 
永远 不 会 出 现 。 

实际 上 ，0bservable<T> 可 以 生成 三 种 类 型 的 事件 。 


Observatble 声明 的 类 型 为 T 的 值 。 
完成 事件 。 
错误 事件 。 


Reactive Extensions 规范 明确 规定 ， 所 有 0bservable 都 可 以 发 布 任意 数量 的 值 ， 并 且 可 以 
跟随 一 个 完成 或 错误 事件 (但 是 不 能 两 者 兼 有 )。 严 格 来 说 ，Rx 设计 指南 将 该 规则 定义 成 
了 如 下 的 形式 : OnNext*(OnCompleted | OnError)?。 其 中 ，OnNext 代表 一 个 新 的 事件 。 有 
意思 的 是 ， 对 这 个 类 似 正则 表达 式 的 规则 的 任意 可 行 的 组 合 都 是 合法 且 有 用 的 。 

口 OnNext OnCompleted 
Observable 发 布 一 个 值 并 优雅 地 终止 。 当 0bservable 代表 一 个 对 外 部 系统 的 请 求 ， 并 
且 我 们 预期 得 到 单个 响应 时 ， 可 以 采用 这 种 形式 。 

口 onNext+ OnCompleted 
Observable 在 终止 之 前 会 发 布 多 个 值 。 它 可 以 代表 从 数据 库 中 读 取 一 个 列表 ， 并 且 将 每 
个 条 目 作 为 单个 值 。 另 外 一 个 例子 是 ， 如 果 某 个 进程 要 长 期 运行 并 最 终 能 够 完成 ， 可 以 
使 用 它 来 跟踪 进程 。 

口 OnNext+ 

事件 的 无 穷 列表 ， 比 如 社交 媒体 网 站 上 的 评论 或 某 个 组 件 的 状态 更 新 (如 鼠标 移动 和 
ping 请 求 )。 这 种 流 是 无 穷 的 ， 并 且 必 须 在 运行 时 消费 。 

口 只 有 OnCompleted 或 , OnError 
这 类 0bservable 只 表示 正常 或 非 正 常 的 终止 。OnError 还 包含 了 导致 流 终止 的 
Throwable。 错 误 是 通过 事件 发 出 的 ， 而 不 是 标准 的 throw 语句 。 

DD OnNext+ OnError 
某 个 流 可 能 会 成 功 地 发 布 一 个 或 多 个 事件 ， 但 最 终 会 失败 。 一 般 而 言 ， 这 意味 着 这 个 流 
应 该 是 无 穷 的 ， 但 期 间 因为 某 种 致命 错误 出 现 了 故障 。 可 以 想象 成 一 组 网 络 数据 包 ， 它 
要 持续 投递 事件 数 个 小 时 ， 但 是 在 某 个 时 间 点 它 可 能 因为 连接 丢失 而 中 断 。 

OnError 通知 非常 有 意思 。 因 为 Observable 异步 的 特性 ， 简 单 地 抛 出 异常 并 没有 太 大 的 意义 。 

相反 ， 必 须要 将 错误 传输 给 对 其 感 兴趣 的 人 ， 这 可 能 会 跨 线程 并 且 需 要 一 段 时 间 。onError 

是 特殊 类 型 的 事件 ， 它 以 函数 式 的 方式 封装 了 异常 。7.1 节 会 介绍 关于 异常 的 更 多 内 容 。 
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除 此 之 外 ， 你 还 可 以 实现 不 发 布 任何 事件 的 Observable， 包 括 完成 或 错误 事件 。 这 样 的 
0bservable 适用 于 测试 ， 如 练习 超时 。 


2.2 ”订阅 来 自 Observable 的 通知 


在 其 他 人 对 0bservable 发 出 的 事件 表示 感 兴 趣 之 前 ，0bservable 实例 不 会 发 布 任何 事件 。 
要 开始 观察 一 个 0bservabLe， 可 以 使 用 subscribe() 方法 族 。 


Observable<Tweet> tweets = //... 

















tweets.subscribe((Tweet tweet) -> 
System.out.println(tweet)); 


上 面 的 代码 片段 通过 注册 一 个 回调 来 订阅 tweets 0bservable。 每 次 tweets 流 决 定 推 送 一 
个 事件 到 下 游 ， 这 个 回调 就 会 被 调用 。RxJava 契约 会 确保 你 的 回调 不 会 同时 在 多 个 线程 
中 触发 ， 即 便 事件 是 从 多 个 线程 中 发 布 的 。subscribe() 有 多 个 重 载 版 本 ， 它 们 更 加 具体 。 
前 文 已 经 提 到 过 ，0bservable 一 般 不 会 抛 出 异常 。 相 反 ， 异 常 是 0bservable 能 够 传播 的 另 
一 种 通知 (事件 ) 类型。 所 以 ， 你 不 能 围绕 着 subscribe() 使 用 try-catch 代码 块 来 捕获 
这 个 过 程 中 的 异常 ， 而 是 提供 一 个 单独 的 回调 ， 如 下 所 示 。 

tweets .subscribe( 


(Tweet tweet) -> { System.out.println(tweet); }, 
(Throwable t) -> { t.printStackTrace(); } 






































一 、 

















) ; 


subscribe() 的 第 二 个 参数 是 可 选 的 。 它 会 通知 在 生成 条 目的 时 候 可 能 会 抛 出 的 异常 ， 保 
证 在 这 个 异常 之 后 ， 不 会 有 其 他 的 Tweet 出 现 。 即 便 你 预计 异常 不 会 出 现 ， 也 应 该 始终 订 
阅 异常 ， 而 不 仅仅 订阅 合法 的 条 目 。 在 0bservable 中 ， 异 常 是 一 等 公民 。 抛 出 的 异常 可 以 
快速 传播 ， 产 生 很 多 的 副作用 ， 比 如 不 一 致 的 数据 结构 或 失败 的 事务 。 一 般 来 说 ， 这 是 很 
好 的 方法 ， 但 异常 通常 并 不 是 致命 的 。 因 此 ， 可 靠 的 系统 应 该 预先 谋划 并 采用 系统 性 的 方 
式 来 处 理 异常 。 这 就 是 Observable 将 其 显 式 建 模 的 原因 。 


第 三 个 可 选 的 回调 让 我 们 能 够 监听 流 的 结束 。 


tweets .subscribe( 
(Tweet tweet) -> { System.out.println(tweet); }, 
(Throwable t) -> { t.printStackTrace(); }, 
() -> {this.noMore();} 









































); 


需要 记 住 ，RxJava 对 于 生成 多 少 条 目 、 何 时 生成 以 及 何 时 停止 并 没有 预 设 的 限制 。 流 可 能 是 
无 穷 的 ， 也 可 能 一 旦 订阅 就 马上 结束 ， 这 取决 于 subscriber 是 否 想 接收 完成 通知 。 如 果 你 一 
开始 就 知道 某 个 流 是 无 穷 的 ， 那 么 订阅 完成 通知 就 没有 意义 了 。 另 一 方面 ， 在 某 些 场景 中 ， 
流 结束 可 能 恰好 是 实际 要 等 待 的 事件 。 举 例 来 说 ， 想 想 跟踪 长 期 运行 的 进程 的 0bservable 
<progress>。 无 论 客户 端 对 于 跟踪 进程 是 否 感 兴趣 ， 它 肯定 想 要 知道 进程 何 时 结束 。 


补充 一 句 ， 通 常 可 以 使 用 Java 8 的 方法 引用 代替 lambda 表达 式 ， 以 提升 代码 的 可 读 性 ， 
如 下 所 示 。 
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tweets .subscribe( 
System.out: :println, 
Throwable: :printStackTrace, 
this: :noMore); 


使 用 observer<T> 捕 获 所 有 的 通知 


实践 证 明 ， 为 subscribe() 提供 所 有 三 个 参数 是 非常 有 用 的 。 因 此 ， 含 有 这 三 个 回调 
的 包装 器 也 会 非常 有 用 。 这 就 是 设计 Observer<T> 的 目的 。0bserver<T> 是 这 三 个 回调 
的 容器 ， 能 够 接收 来 自 0bservable<T> 的 所 有 可 能 的 通知 。 如 下 的 代码 展现 了 如 何 注 册 


Observable<T>。 


























Observer<Tweet> observer = new Observer<Tweet>() { 
@Override 
public void onNext(Tweet tweet) { 
System.out.println(tweet); 
} 


@Override 
public void onError(Throwable e) { 
e.printStackTrace(); 


} 
@Override 
public void onCompleted() { 
noMore(); 
} 
}; 
A: 


tweets .subscribe(observer); 


实际 上 ，0bserver<T> 是 RxJava 监听 功能 的 核心 抽象 。 不 过 ， 如 果 你 想 要 更 好 地 进行 控制 ， 
Subscriber (Observer 抽象 的 实现 ) 更 加 强大 。 


2.3 使 用 Subscription 和 Subscriber<T> 控 制 监 听 器 


一 个 Observable 可 以 有 多 个 订阅 者 。 类 似 于 发 布 者 - 订阅 者 模式 ， 一 个 发 布 者 可 以 分 发 事 
件 给 多 个 消费 者 。 在 RxJava 中 ，0bservable<T> 只 是 一 个 类 型 化 数据 结构 ， 它 可 能 存活 很 
短 的 时 间 ， 也 可 能 只 要 服务 器 程序 在 运行 ， 它 就 持续 存活 。 对 于 订阅 者 来 说 也 是 如 此 。 你 
可 以 订阅 一 个 Observable， 消 费 一 些 事件 ， 抛 弃 其 他 的 事件 。 也 可 以 采用 完全 相反 的 做 
法 : 只 要 0bservable 存活 ， 就 一 直 抽 取 事 件 ， 或 许 能 持续 几 个 小 时 或 几 天 。 

假设 某 个 0bserver 预先 知道 它 想 要 接收 多 少 条 目 或 者 何 时 停止 接收 。 比 如 ， 我 们 订阅 了 
股票 价格 变化 的 消息 ， 但 是 如 果 价 格 低 于 1 美元 ， 我 们 将 不 再 监听 。 显 然 ，0bserver 有 订 
阅 的 能 力 ， 那 么 它 也 应 该 具有 在 合适 的 情况 下 取消 订阅 的 能 力 。 有 两 种 方式 支持 该 功能 : 
Subscription 和 Subscriber。 先 讨论 一 下 前 者 。 这 里 不 探讨 subscribe() 实际 会 返回 什么 。 
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Subscription subscription = 
tweets. subscribe(System.out::println); 


{es 
subscription.unsubscribe(); 


Subscription 是 一 个 句柄 ， 人 允许 客户 端 代码 通过 unsubscribe() 方 法 取消 订阅 。 除 此 之 
外 ， 你 还 可 以 通过 isunsubscribed() 查询 订阅 的 状态 。 不 想 接 收 更 多 事件 的 时 候 ， 取 消 对 
Observable<T> 的 订阅 是 非常 重要 的 ， 这 能 够 避免 内 存 泄漏 和 不 必要 的 系统 负载 。 有 时 候 我 
们 会 订阅 并 完整 消费 一 个 Observable， 即 便 这 个 流 古 无 穷 的 ， 也 永远 不 会 真正 取消 订阅 。 
但 是 ， 也 存在 订阅 者 来 来 去 去 ，0bservable 却 在 持续 生成 事件 的 情况 。 
还 有 第 二 种 方式 能 取消 订阅 ， 这 次 是 在 监听 者 内 部 实现 。 我 们 已 经 知道 ， 可 以 通过 
Subscription 在 Observer 或 回调 之 外 控制 订阅 情况 。 而 Subscriber<T> 同 时 实现 了 
Observer<T> 和 Subscription。 因 此 ， 它 既 能 够 用 来 消费 通知 (事件 、 完 成 或 错误 信息 )， 
又 能 够 控制 订阅 。 如 下 的 示例 代码 订阅 了 所 有 的 事件 ， 但 是 订阅 者 本 身 会 在 满足 特定 标准 
的 时 候 放 弃 接 收 通知 。 正 常情 况 下 ， 可 以 通过 内 置 的 takeUntiL() 操作 符 来 完成 该 功能 ， 
目前 也 可 以 手动 取消 订阅 。 
Subscriber<Tweet> subscriber = new Subscriber<Tweet>() { 
@Override 
public void onNext(Tweet tweet) { 


if (tweet.getText().contains("Java")) { 
unsubscribe(); 

















} 
} 


@Override 
public void onCompleted() {} 


@Override 
public void onError(Throwable e) { 
e.printStackTrace(); 
} 
}; 
tweets .subscribe(subscriber); 
Subscriber 决定 不 再 接收 更 多 条 目 时 ， 它 可 以 自己 取消 订阅 。 作 为 练习 ， 你 可 以 实现 一 个 
Subscriber ， 它 只 接收 前 n 个 事件 ， 然 后 放弃 接收 事件 。Subscriber 类 还 有 更 强大 的 功能 ， 
但 是 目前 记 住 它 能 够 自己 取消 对 0bservable 订阅 即 可 。 


2.4 ”创建 Observable 


本 书 首先 介绍 了 订阅 0bservable 以 接收 那些 推送 到 下 游 的 事件 。 这 并 非 巧 合 ， 在 使 用 
RxJava 的 大 多 数 情况 下 ， 我 们 都 会 与 已 有 的 0bservable 交互 ， 一般 会 对 它们 进行 组 合 、 
过 滤 和 包装 。 除 非 你 使 用 的 外 部 API 暴露 了 0bservable， 否 则 你 必须 先 了 人 解 Observable 
来 自 哪 里 ， 以 及 如 何 创建 流 和 处 理 订阅 。 首 先 ， 有 一 些 工厂 方法 能 够 创建 固定 的 常量 
Observable。 如 果 你 想 在 整个 代码 库 中 前 后 一 致 地 使 用 RxJava， 或 者 要 发 布 的 值 生成 成 本 












































大 和 
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很 低 并 预先 知道 它 的 内 容 ， 那 么 这 种 方式 是 很 有 用 的 。 
DD Observable.just(value) 
创建 一 个 Observable 实例 ， 它 只 给 所 有 未 来 的 订阅 者 发 布 一 个 值 ， 随 后 正常 完成 。 重 
载 版 本 的 just() 操作 符 还 能 发 布 2 到 9 个 值 。 
DD Observable.from(values) 
类 似 于 just(), 但 是 它 接受 Iterable<T> 或 T[] 作为 参数 ， 因 此 它 创 建 的 Observable<T> 
发 布 的 值 就 是 values 集合 中 的 元 素 。 另 外 一 个 重 载 版 本 接受 Future<T>， 底 层 Future 
完成 的 时 候 会 发 布 一 个 事件 。 
口 Observable.range(from, n) 
从 from 开始 生成 n 个 整 型 数字 。 例 如 ，range(5，3) 将 会 发 布 5、6 和 7， 然 后 正常 完 
成 。 每 个 订阅 者 会 接收 到 一 组 相同 的 数字 。 
口 Observable.empty() 
订阅 后 立即 完成 ， 不 发 布 任何 的 值 。 
口 Observable.never() 
这 样 的 Observable 不 发 布 任何 的 通知 ， 无 论 是 值 ， 还 是 完成 或 失败 。 这 个 流 适用 于 测试 。 
口 Observable.error() 
立即 给 每 个 订阅 者 发 送 一 个 onError() 通知 。 不 发 布 任何 的 值 ， 按 照 契 约 ， 也 不 会 发 送 
onCompleted() 通知 。 















































2.4.1 掌握 Observable.create() 


empty()、never() 和 error() 工厂 方法 看 上 去 似乎 没有 太 大 的 用 处 ， 但 是 它们 与 真正 的 
Observable 组 合 时 是 非常 便利 的 。 有 意思 的 是 ， 尽 管 RxJava 就 是 异步 处 理事 件 流 ， 上 述 
的 工厂 方法 却 默认 是 在 客户 端 线程 中 执行 的 。 请 看 下 述 的 代码 样 例 。 
private static void log(Object msg) { 
System.out.printLn( 


Thread.currentThread() .getName() + 
" + nsg); 

















} 
/fi 


log("Before"); 
Observable 
.range(5, 3) 
.Subscribe(i -> { 
log(i); 
]); 
log("After"); 


我 们 感 兴趣 的 是 执行 每 个 日 志 语 句 的 线程 。 


main: Before 
main: 5 
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main: 6 
main: 7 
main: After 


print 语句 的 顺序 也 是 值得 关注 的 。Before 和 After 消息 是 由 main 客户 端 线程 打印 出 来 
的 ， 这 一 点 倒 不 令 人 惊讶 。 但 是 ， 请 注意 订阅 也 是 发 生 在 客户 端 线程 中 的 ，subscribe() 
实际 上 会 阻塞 客户 端 线程 ， 直 到 所 有 的 事件 都 被 接收 。 除 非 某 些 操作 符 需 要 ， 否 则 RxJava 
不 会 隐 式 地 在 线程 池 中 运行 代码 。 为 了 更 好 地 理解 这 种 行为 ， 接 下 来 学 习 用 来 生成 
Observable 的 一 个 低层 级 的 操作 符 ， 即 create()。 


Observable<Integer> ints = Observable 
.Create(new Observable.OnSubscribe<Integer>() { 

@Override 

public void call(Subscriber<? super Integer> subscriber) { 
log("Create"); 
subscriber .onNext(5); 
subscriber .onNext(6); 
subscriber .onNext(7); 
subscriber .onCompleted(); 
log("Completed"); 








} 
}); 


log("Starting"); 
ints.subscribe(i -> Log("ELement: " + i)); 
log("Exit"); 


上 面 的 示例 代码 有 意 写 得 比较 元 长 。 如 下 是 输出 ， 包 括 执行 每 行 代码 的 线程 名 称 。 


main: Starting 

main: Create 

main: Element: 5 

main: Element: 6 

main: Element: 7 

main: Completed 

main: Exit 
为 了 理解 Observable.create() 是 如 何 运 行 的 ， 以 及 RxJava 是 如 何 处 理 并 发 的 ， 接 下 来 将 
逐 行 分 析 它 的 执行 过 程 。 首 先 ， 样 例 为 create() 方法 提供 一 个 onSubscribe 回调 接口 的 实 
现 ， 以 创建 名 为 ints 的 observabte ( 稍 后 ， 基 本 上 会 用 简单 的 lambda 表达 式 来 替代 它 )。 
现在 ， 除 了 创建 0bservable 实例 之 外 ， 还 没有 发 生 任何 事情 ， 所 以 第 一 行 输出 的 是 maiin: 
Starting。O0bservable 默认 会 延迟 事件 的 发 布 ， 所 以 为 create() 提供 的 lambda 表达 式 并 
没有 执行 。 随 后 ， 订 阅 ints.subscribe(...)， 强 制 Observable 开始 发 布 条 目 。 对 于 cold 
类 型 的 流 来 说 ， 这 些 情况 都 是 成 立 的 。 但 是 ， 对 于 hot 类 型 的 流 来 说 ， 情 况 会 有 所 不 同 : 
不 管 有 没有 人 订阅 ， 它 都 会 发 布 事件 。2.4.4 市 将 会 曾 述 它们 的 差别 。 


接收 发 布 条 目的 lambda 表达 式 (i -> log("Element: " + i) 在 内 部 会 被 
Subscriber<Integer> 包装 。 调 用 create() 时 ， 这 个 订阅 者 基本 上 会 直接 作 
为 参数 传递 给 指定 的 函数 。 所 以 ， 每 订阅 一 个 0bservable， 就 会 创建 一 个 新 
的 Subscriber 实例 并 传递 给 create() 方法 。 在 create() 中 ， 调 用 onNext() 
或 Subscriber 的 其 他 方法 会 间接 触发 你 自己 的 Subscriber。 





















































入 后 


28 | 第 2 章 





Observable.create() 的 用 途 非 常 广泛 ， 实 际 上 ， 你 可 以 基于 它 模拟 之 前 提 到 的 各 个 工厂 方 
法 。 例 如 ，0bservable.just(x) 会 发 布 单个 值 x 并 立即 结束 ， 看 起 来 可 能 会 是 这 样 的 : 


static <T> Observable<T> just(T x) { 
return Observable.create(subscriber -> { 
subscriber .onNext(x); 
subscriber .onCompleted(); 








} 
); 
} 


作为 练习 ， 请 尝试 实现 never()、empty()， 甚 至 仅 用 create() 实现 range()。 

管理 多 个 订阅 者 

如 果 没 有 实际 订阅 ， 事 件 是 不 会 发 布 的 。 但 是 ， 每 次 调用 subscribe() 的 时 候 ，create() 

中 的 订阅 句柄 也 会 被 调用 。 这 说 不 上 是 什么 优势 或 劣势 ， 只 是 需要 记 住 这 一 点 。 在 有 些 场 

景 下 ， 每 个 订阅 者 都 能 对 应 唯一 的 句柄 调用 是 非常 棒 的 。 例 如 ，0bservable.just(42) 会 将 

42 发 布 给 每 个 订阅 着 ， 而 不 是 只 给 第 一 个 订阅 者 。 另 一 方面 ， 如 果 你 要 在 create() 中 进 
行 数据 库 查 询 或 重量 级 的 计算 ， 那 么 所 有 的 订阅 者 共享 同一 次 调用 就 会 带 来 一 定 的 收益 


为 了 保证 你 真正 理解 订阅 是 如 何 运行 的 ， 不 妨 芳 虑 如 下 的 样 例 ， 它 对 同一 个 Observable 订 
阅 了 两 次 。 
Observable<Integer> ints = 
Observable.create(subscriber -> { 
log("Create"); 


subscriber .onNext(42); 
subscriber .onCompleted(); 



























































} 
); 
log("Starting"); 
ints.subscribe(i -> log("Element A: " + i)); 
ints.subscribe(i -> log("Element B: " + i)); 
log("Exit"); 


你 预期 的 输出 是 什么 样子 的 呢 ? 记 住 ， 每 当 订 阅 通过 create() 工厂 方法 生成 的 0bservable， 
作为 参数 传递 给 create() 的 lambda 表达 式 都 会 默认 在 初始 化 订阅 的 线程 中 独立 执行 。 


main: Starting 
main: Create 

main: Element A: 42 
main: Create 

main: Element B: 42 
main: Exit 


如 果 你 不 想 为 所 有 订阅 者 调用 create()， 而 是 想 重用 已 经 计算 的 事件 ， 那 么 可 以 使 用 非常 
便利 的 cache() 操作 符 。 
Observable<Integer> ints = 


Observable.<Integer>create(subscriber -> { 


ye 

















} 
) 


.cache(); 
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cache() 是 我 们 学 习 的 第 一 个 操作 符 。 操 作 符 会 包装 并 增强 已 有 的 0bservable， 一 般 通 过 
对 订阅 进行 拦截 来 实现 。cache() 做 的 事情 位 于 subscribe() 和 自 定义 的 Observable 之 间 。 
第 一 个 订阅 者 出 现时 ，cache() 将 订阅 委托 给 底层 的 Observable， 然 后 将 所 有 的 通知 ( 事 
件 、 完 成 或 错误 ) 转发 给 下 游 。 但 是 ， 它 同时 还 会 在 内 部 保留 所 有 通知 的 一 个 副本 。 如 果 
后 续 的 订阅 者 希望 接收 已 推送 的 通知 ，cache() 不 会 再 委托 给 底层 的 0bservable， 而 是 将 
缓存 的 值 发 布 出 来 。 在 使 用 缓存 时 ， 两 个 Subscriber 的 输出 会 有 很 大 的 差异 ， 如 下 所 示 。 
































main: Starting 
main: Create 

main: Element A: 42 
main: Element B: 42 
main: Exit 























当然 ,一 定 要 记 住 de 和 无 穷 流 组 合 将 会 带 来 灾难 性 的 结果 ， 也 就 是 0utOfMemoryError。 
8.6 节 将 会 对 其 进行 介 


2.4.2 无 穷 流 


无 穷 的 数据 结构 是 很 重要 的 概念 。 计 算 机 的 内 存 是 有 限 的 ， 因 此 无 穷 的 列表 或 流 听 起 来 似 
平 是 不 可 能 实现 的 。 但 是 ，RxJava 允许 动态 地 生成 和 消费 事件 。 传 统 队列 可 以 视 为 无 穷 值 
的 来 源 ， 只 不 过 它 不 会 同时 将 所 有 的 值 都 保存 在 内 存 之 中 。 那 么 ， 该 如 何 使 用 create() 实 
现 这 样 的 无 穷 流 呢 ?” 例 如 ， 创 建 一 个 生成 所 有 自然 数 的 Observable。 



































// 有 问题 ! 不 要 这 样 做 
Observable<BigInteger> naturalNumbers = 0bservabLe.create( 
subscriber -> { 
BigInteger i = ZERO; 
while (true) { // 不 要 这 样 做 ! 
subscriber .onNext(i); 
i = i.add(ONE); 





} 
]); 


naturalNumbers.subscribe(x -> log(x)); 


人 while(true) 这 种 编码 方式 都 会 引发 告警 。 这 看 上 去 没有 毛病 ， 但 
很 快 你 就 会 意识 到 这 个 实现 是 有 问题 的 。 不 过 ， 这 并 非 因 为 它 是 无 穷 的 ， 实 际 上 无 穷 的 
Observable 是 完全 可 以 的 ， 而 且 非 常 有 用 。 当 然 ， 前 提 是 它 要 以 恰当 的 方式 来 实现 。 调 用 
subscribe() 时 ，create() 中 的 lambda 表达 式 将 会 在 你 的 线程 的 上 下 文中 执行 。 因 为 这 个 
lambda 表达 式 永 远 不 会 结束 ，subscribe() 也 就 会 永远 地 阻塞 。 你 可 能 会 问 :“ 订 阅 难道 
不 应 该 是 异步 的 吗 ? 那 为 什么 会 在 客户 端 线程 中 运行 订阅 句柄 呢 ? ”这 是 一 个 很 合理 的 问 
题 ， 所 以 下 面 花 点 时 间 来 介绍 显 式 的 并 发 ， 如 下 所 示 。 





















































Observable<BigInteger> naturaLNumbers = 0bservabLe.create( 
subscriber -> { 
Runnable r = () -> { 
BigInteger i = ZERO; 
while (!subscriber.isUnsubscribed()) { 
subscriber .onNext(i); 
i = i.add(ONE); 





new Thread(r).start(); 
]); 











这 里 不 再 是 在 客户 端 线程 中 直接 运行 阻塞 循环 ， 而 是 生成 了 一 个 自 定义 的 线程 ， 在 该 线程 
中 发 布 事件 。 现 在 ，subscribe() 不 会 再 阻塞 客户 端 线程 ， 因 为 它 底层 做 的 事情 仅仅 是 生 
成 一 个 线程 。x -> log(x) 回调 的 所 有 调用 都 会 在 自 定义 线程 的 后 台 执行 。 假 设 现在 我 们 









































不 再 对 所 有 的 自然 数 感 兴 趣 (毕竟 它们 的 数量 大 多 了 ) ， 只 对 前 面 的 一 部 分 感 兴趣 。 
已 经 知道 了 如 何在 observablte 中 停止 接收 通知 一 一 通过 取消 订阅 功能 。 
Subscription subscription = naturalNumbers.subscribe(x -> log(x)); 


// 一 段 时 间 之 后 …… 


subscription.unsubscribe(); 


如 有 果 你 关注 细节 ， 会 发 现 看 上 去 非常 可 疑 的 while(true) 循环 已 经 被 替换 成 以 下 代码 


while (!subscriber.isUnsubscribed()) { 


我 们 发 起 的 每 一 次 迭代 ， 都 需要 确保 有 人 在 进行 监听 。 某 个 订阅 者 决定 停止 监 








我 们 


o 


听 时 ， 





subscriber.isUnsubscribed() 条 件 就 会 发 出 通知 ， 这 样 ， 我 们 就 能 安全 地 完成 流 并 退出 





Runnable， 实 际 上 也 就 是 停止 了 该 线程 。 显 然 ， 每 个 订阅 者 都 有 自己 的 线程 和 循环 ， 


所 以 


即使 某 个 订阅 者 决定 取消 订阅 ， 其 他 的 订阅 者 依然 能 够 接收 其 独立 的 事件 流 。 尽 管 创建 自 
己 的 线程 并 不 是 好 的 设计 决策 ，RxJava 也 有 更 好 的 声明 式 工 具 来 处 理 并 发 ， 但 是 上 述 的 代 














码 样 例 依然 展现 了 如 何 恰 当地 处 理 订 阅 事件 。 








建议 尽 可 能 频繁 地 检查 isUnsubscribed() 标记 ， 从 而 避免 将 事件 发 送 给 那些 已 经 不 再 想 接 























收 新 事件 的 订阅 者 。 此 外 ， 当 生成 事件 的 成 本 很 高 的 时 候 ， 如 果 没 有 人 想 接收 事件 ， 








再 急 


切 地 将 它们 发 送出 来 就 没有 意义 了 。 自 行 生成 线程 的 做 法 本 质 上 没有 什么 问题 ,但 是 它 容 
易 出 错 ， 并 且 扩 展 性 很 差 。4.9 市 会 探讨 声明 式 并 发 和 自 定义 调度 器 。 这 些 特 性 允许 我 们 











编写 并 发 的 代码 ， 而 不 必 自 己 与 线程 进行 真正 的 交互 。 



































如 有 果 事件 推送 的 频率 相对 很 高 ， 在 发 送 事件 之 前 处 理 取消 订阅 是 一 种 不 错 的 办 法 。 但 是 ， 


假设 在 一 个 场景 中 事件 发 生 的 频率 非常 低 ，0bservable 只 有 在 试图 推送 事件 的 时 候 才 能 判 
断 订 阅 者 是 否 已 经 取消 了 订阅 。 以 下 面 这 个 很 有 用 的 工厂 方法 为 例 ; delayed(x) 会 创建 
一 个 0bservabLe， 该 0bservable 在 休眠 10 秒 之 后 会 发 布 一 个 值 x。 它 类 似 于 0bservable. 
just()， 但 有 额外 的 延迟 。 这 时 需要 一 个 额外 的 线程 ， 尽 管 这 并 不 是 最 佳 的 使 用 模式 ， 如 











下 所 示 。 


static <T> Observable<T> delayed(T x) { 
return 0bservabLe.create( 
subscriber -> { 
Runnable r = () -> { 

sleep(10, SECONDS); 

if (!subscriber.isUnsubscribed()) { 
subscriber .onNext(x); 
subscriber .onCompleted(); 


} 


new Thread(r).start(); 
]); 
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} 


static void sleep(int timeout, TimeUnit unit) { 
try { 
unit.sleep(timeout); 
} catch (InterruptedException ignored) { 
// 有 意 忽略 
} 
} 


这 里 的 原始 实现 会 生成 一 个 新 的 线程 并 休眠 10 秒 。 更 为 健壮 的 实现 方式 至 少 要 使 用 java. 
util.concurrent.ScheduledExecutorService， 但 仅 用 于 教学 。 在 10 秒 之 后 ， 确 保 依 然 还 
有 人 在 监听 ， 如 果 确 实 如 此 ， 就 发 布 一 个 条 目 并 完成 。 但 是 ， 如 果 订 阅 者 在 订阅 1 秒 之 后 
就 决定 取消 订阅 会 怎么 样 呢 ， 也 就 是 比 理应 发 布 事 件 的 时 间 早 得 多 ?这 也 没什么 。 后 台 线 
程 继续 休眠 9 秒 ， 然 后 才 会 意识 到 订阅 者 已 经 不 存在 了 。 这 里 就 是 令 人 困扰 的 地 方 ， 额 外 
再 持 有 资源 9 秒 是 非常 浪费 的 。 假 设 这 是 一 个 到 数据 feed 的 连接 ， 它 的 成 本 非常 高 ， 使 用 
它 需 按 秒 付费 ， 但 是 事件 的 发 生 频 率 却 非常 低 。 等 待 数秒 ， 其 至 数 分 钟 ， 才 能 发 现 没 有 人 
订阅 并 终止 连接 。 这 样 的 做 法 并 不 是 最 优 的 。 
幸而 ， 借 助 subscriber 实例 可 以 在 取消 订阅 之 时 马上 得 到 通知 ， 并 立即 清理 资源 ， 不 用 等 
到 下 一 条 消息 出 现 才 进行 这 些 操 作 。 
static <T> Observable<T> delayed(T x) { 
return Observable.createl( 
subscriber -> { 
Runnable r = () -> {/* ... */}; 
final Thread thread = new Thread(r); 
thread. start(); 
subscriber .add(Subscriptions.create(thread: :interrupt)); 


}); 






























































} 


最 后 一 行 最 重要 ， 但 其 他 的 内 容 也 不 能 忽略 。 后 台 线 程 已 经 运行 了 ， 或 者 更 精确 地 说 ， 它 
已 经 开始 10 秒 休眠 了 。 但 是 ， 生 成 线程 之 后 ， 通 过 一 个 回调 要 求 订 阅 者 告知 我 们 它 是 否 
取消 了 订阅 ， 这 是 通过 Subscriber.add() 注册 的 。 这 个 回调 只 有 一 个 很 简单 的 目的 : 中 
断 线 程 。 调 用 Thread.interrupt() 之 后 ， 将 会 在 sleep() 中 抛 出 InterruptedException， 
提前 中 断 10 秒 休 眠 。stLeep() 在 接收 到 这 个 异常 之 后 ， 就 会 优雅 地 退出 。 但 是 ， 此 时 
subscriber.isUnsubscribed() 返回 true， 并 没有 发 出 任何 事件 。 线 程 马 上 结束 ， 不 会 浪费 
任何 资源 。 你 可 以 采用 这 种 模式 执行 任意 的 清理 工作 。 但 是 ， 如 果 流 生成 的 是 稳定 、 频 繁 
的 事件 ， 那 么 你 可 能 就 不 需要 显 式 回调 。 


还 有 一 个 不 应 该 在 create() 中 使 用 显 式 线程 的 原因 。Rx 设计 指南 的 4.2 节 (“假定 观察 者 
实例 以 序列 化 的 方式 被 调用 ”) 要 求 订 阅 者 不 能 并 发 地 接收 通知 。 涉 及 显 式 的 线程 时 ， 很 
容易 违反 这 个 要 求 。 这 种 行为 类 似 于 Akka 工具 集中 的 Actor， 在 那里 每 个 Actor 一 次 只 能 
处 理 一 条 消息 。 按 照 这 样 的 假设 ， 可 以 编写 同步 的 0bserver， 通 常 只 能 由 一 个 线程 进行 访 
间 。 即 便 事件 是 由 多 个 线程 发 出 的 ， 这 个 假设 依然 成 立 。0bservable 的 自 定义 实现 必须 要 
确保 满足 这 个 契约 。 如 下 的 代码 试图 并 行 加 载 多 个 块 的 bnata， 这 并 不 符合 习惯 的 用 法 。 

















































































































Observable<Data> loadAll(Collection<Integer> ids) { 
return Observable.create(subscriber -> { 
ExecutorService pool = Executors.newFixedThreadPool(10); 
AtomicInteger countDown = new AtomicInteger(ids.size()); 
// 和 危险， 这 违反 了 Rx 契 约 。 不 要 这 样 做 ! 
ids.forEach(id -> pool.submit(() -> { 
final Data data = load(id); 
subscriber .onNext(data); 
if (countDown.decrementAndGet() == 0) { 
pool.shutdownNow(); 
subscriber .onCompleted(); 











这 段 代 码 除了 特别 复杂 之 外 ， 还 违反 了 一 些 Rx 原则 。 也 就 是 说 ， 它 允许 从 多 个 线程 并 发 
地 调用 subscriber 的 onNext() 方 法。 其 次 ， 使 用 RxJava 的 惯用 操作 符 就 可 以 避免 这 种 
复杂 性 ， 比 如 merge() 和 flatMap()， 但 是 3.2.1 节 才 会 对 其 进行 讨论 。 好 消息 是 ， 即 便 有 
人 将 Observable 实现 得 非常 糟糕 ， 我 们 依然 可 以 通过 seriatLize() 操作 符 来 修正 它 ， 比 如 
loadAl1(...).serialize()。 这 个 操作 符 能 够 确保 事件 是 序列 化 和 有 序 的 ， 它 还 能 确保 完成 
和 错误 之 后 ， 不 会 再 有 事件 发 出 。 


在 创建 0bservable 方面 ， 还 没有 提 及 的 一 个 问题 是 错误 传播 。 到 目前 为 止 ， 本 章 已 经 介绍 了 
Observer<T> 能 够 接收 T 类 型 的 值 ， 还 有 可 选 的 完成 或 错误 事件 。 但 是 ， 该 如 何 将 错误 推送 
至 下 游 所 有 的 订阅 者 呢 ? 最 佳 的 做 法 是 在 create() 方法 中 ， 将 所 有 的 表达 式 都 包装 在 一 个 
try-catch 代码 块 中 。Throwable 应 该 传播 至 下 游 ， 而 不 是 打印 日 志 或 重新 抛 出 ， 如 下 所 示 。 


Observable<Data> rxLoad(int id) { 
return Observable.create(subscriber -> { 
try { 
subscriber .onNext(load(id)); 
subscriber .onCompleted(); 
} catch (Exception e) { 
subscriber .onError(e); 



































}); 

} 
额外 的 try-catch 代码 块 是 非常 必要 的 ， 它 会 传播 可 能 被 抛 出 的 Exception， 比 如 Load(id) 
抛 出 的 Exception。 否 则 ，RxjJava 最 多 只 能 将 异常 打印 在 标准 输出 上 。 但 是 为 了 构建 弹 
性 流 ， 异 常 需要 被 当 作 一 等 公民 对 待 ， 而 不 能 仅仅 是 编程 语言 中 没有 人 能 真正 理解 的 额 
外 特性 。 


Observable 通过 一 个 值 来 结束 ， 并 且 使 用 try-catch 来 进行 包装 是 非常 常见 的 模式 ， 所 以 
RxJava 引入 了 内 置 的 fromCallable() 操作 符 。 
Observable<Data> rxLoad(int id) { 


return Observable.fromCallable(() -> 
load(id)); 
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在 语义 上 ， 它 与 前 面 的 代码 相同 ， 但 是 更 加 简短 。 除 此 之 外 ， 相 对 于 create()， 它 还 有 一 
些 其 他 的 优点 ， 稍 后 会 介绍 。 














2.4.3 计时 : timer() 和 interval() 


我 们 已 经 介绍 了 0bservable 如 何 自行 创建 线程 ， 但 它 在 RxJava 中 并 不 是 最 好 的 模式 。 后 
而 的 章节 会 介绍 调度 器 ， 但 是 我 们 先 来 了 解 一 下 两 个 非常 有 用 的 操作 符 ， 也 就 是 timer() 
和 ;intervaL()， 它 们 在 底层 会 用 到 线程 。 前 者 只 是 简单 地 创建 一 个 0bservable， 在 特定 的 
延迟 后 发 布 一 个 Long 类 型 的 零 值 ， 然 后 完成 。 

Observable 


.timer(1, TimeUnit.SECONDS) 
.subscribe((Long zero) -> log(zero)); 


虽然 看 起 来 很 傻 ， 但 是 timer() 非常 有 用 。 基 本 上 ， 它 就 是 一 个 异步 版 本 的 Thread. 
sleep()。 我 们 创建 了 一 个 Observable 并 通过 subscribe() 订阅 它 ， 而 不 是 阻塞 当前 线程 。 
学 习 如 何 将 简单 的 Observable 组 合 为 更 复杂 的 计算 形式 之 后 ， 它 将 变 得 更 加 重要 。 固 定 的 
值 零 (在 zero 变量 中 ) 只 是 一 个 约定 ， 并 没有 任何 特殊 的 含义 。 不 过 ， 引 入 interval() 
之 后 ， 就 会 更 有 意义 了 。interval() 会 生成 一 个 long 类 型 数字 的 序列 ， 从 零 开 始 ， 每 个 数 
字 之 间 有 固定 的 时 间 间 隔 。 

Observable 


.interval(1 000 000 / 60, MICROSECONDS) 
.subscribe((Long i) -> log(i)); 


Observable.interval() 会 从 零 开始 生成 一 系列 long 类 型 的 连续 数字 。 但 是 ， 与 range() 
不 同 ，interval() 会 在 每 个 事件 之 前 添加 固定 的 时 间 间 隔 ， 包 括 第 一 个 。 样 例 中 的 这 个 延 
迟 大 约 是 16 666 ns， 大 致 对 应 为 60 Hz， 这 也 是 各 种 动画 中 常用 的 帧 率 。 这 并 不 是 巧合 : 
interval() 有 了 时 用 来 控制 需要 以 特定 频率 运行 的 动画 或 进程 。 某 种 程度 上 ，interval() 类 
似 于 ScheduledExecutorService 中 的 scheduleAtFixedRate()。 你 可 以 想象 一 下 interval() 
的 多 种 使 用 场景 ， 比 如 定期 轮 询 数据 、 刷 新 用 户 界面 或 者 建 模 时 间 的 推移 。 













































































2.4.4 ”hot 和 cold 类 型 的 0bservable 


在 得 到 一 个 Observable 实例 之 后 ， 很 重要 的 一 点 是 要 理解 它 是 hot 类 型 的 还 是 cold 类 型 
的 。 它 们 的 API 和 语义 是 相同 的 ， 但 是 使 用 0bservable 的 方法 取决 于 它 的 类 型 。cold 类 
型 的 Observable 完全 是 延迟 (lazy) 执行 的 ， 并 且 在 有 人 对 其 感 兴 趣 时 才 会 开始 发 布 事 
件 。 如 果 没 有 观察 者 ， 那 么 0bservable 只 是 一 个 静态 的 数据 结构 。 这 也 意味 着 ， 每 个 订 
阅 者 都 会 接收 到 属于 自己 的 流 的 副本 ， 因 为 事件 是 延迟 生成 的 ， 并 且 一 般 不 会 采取 任何 
形式 的 缓存 。cold 类 型 的 0Observable 通常 来 源 于 0bservable.create()， 按 照 语 义 ， 它 不 
会 启用 任何 逻辑 ， 而 是 推迟 到 有 人 实际 对 其 监听 才 会 执行 。 从 某 种 程度 上 来 说 ，cold 类 型 
的 Observable 依赖 Subscriber。cold 类 型 的 0bservablte 的 样 例 除 了 create() 之 外 ， 还 包 
括 Observable.just()、from() 和 range()。 订 阅 一 个 cold 类 型 的 0bservabtLe 通常 还 涉及 
create() 中 的 副作用 ， 比 如 查询 数据 库 或 打开 连接 。 


hot 类 型 的 0bservable 则 与 之 不 同 。 在 得 到 这 种 类 型 的 0bservablte 的 时 候 ， 不 管 是 否 
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有 Subscriber， 它 都 可 能 已 经 开始 发 布 事 件 了 。 即 便 疫 有 人 监听 ， 事 件 可 能 会 丢失 ， 
Observable 依然 会 往 下 游 推送 事件 。 通 常情 况 下 ， 可 以 完全 控制 cold 类 型 的 0bservabte， 
但 是 hot 类 型 的 0bservable 是 独立 于 消费 考 的 。Subscriber 出 现时 ，hot 类 型 的 
0bservable 的 行为 类 似 于 电话 窃听 (wire tap)， 透 明 地 发 布 流 经 它 的 事件 。Subscriber 的 出 
现 和 消失 并 不 会 改变 0bservable 的 行为 ， 它 是 完全 解 耦 和 独立 的 。 

稍 感 意外 的 是 ，0bservable.interval() 并 不 是 hot 类 型 的 Observable。 你 可 能 认为 它 只 
是 每 隔 固定 的 时 间 生 成 报时 信号 ， 与 环境 并 没有 什么 关系 ， 但 实际 上 上， 只 有 有 人 订阅 的 
时 候 ， 才 会 生成 计时 器 事件 ， 而 每 个 订阅 者 会 得 到 独立 的 流 。 这 完全 符合 cold 类 型 的 
Observable 的 定义 。 


hot 类 型 的 Observable 通常 发 生 在 完全 无 法 控制 事件 源 的 场景 下 。 这 种 Observable 的 样 
例 包括 鼠标 移动 、 键 盘 输 入 或 按钮 点 击 。 到 目前 为 止 ， 还 没有 提 及 用 户 界 面 ， 但 事实 上 ， 
RxJava 非常 适合 用 户 界面 的 实现 。 这 个 库 在 Android 社区 特别 受 欢 迎 ， 它 能 够 帮助 开发 人 
员 将 嵌 套 回调 转换 为 扁平 化 的 流 组合 。8.1 节 将 探索 如 何在 运行 Android 系统 的 移动 设备 上 
使 用 RxJava。 


依赖 事件 传递 时 ，hot 类 型 和 cold 类 型 0bservable 的 差异 就 变 得 非常 重要 了 。 不 管 立 即 订 
阅 还 是 几 个 小 时 之 后 订阅 cold 类 型 的 Observable， 你 都 会 获得 完整 且 一 致 的 事件 集 。 但 
如 果 0bservable 是 hot 类 型 的 ， 那 么 你 就 无 法 确保 能 接收 到 所 有 事件 。 本 章 稍 后 将 介绍 
一 些 技术 ， 它 们 能 够 确保 每 个 订阅 者 都 能 接收 到 所 有 事件 ， 其 中 一 项 本 章 已 经 介绍 过 了 : 
cache() 操作 符 (参见 2.4.1 节 )。 在 技术 上 来 讲 ， 可 以 缓冲 来 自 hot 类 型 0bservablte 的 所 
有 事件 ， 让 后 续 的 订阅 者 都 能 接收 到 相同 的 事件 序列 。 但 是 ， 在 理论 上 ， 它 消耗 的 内 存量 
是 没有 限制 的 ， 所 以 在 缓存 hot 类 型 的 0bservable 时 要 非常 小 心 。 


hot 源 和 cold 源 的 时 间 依 赖 性 是 另外 一 个 值得 注意 的 差异 。cold 类 型 的 observable 按 需 生 
成 值 ， 并 且 可 能 会 生成 多 次 ， 所 以 某 个 条 目的 确切 生成 时 间 无 关 紧 要 。 但 是 ，hot 类 型 的 
Observable 一 般 代表 的 是 外 部 源 生成 的 事件 。 这 意味 着 给 定 值 的 生成 时 间 是 非常 重要 的 ， 
为 它 能 够 将 事件 限定 在 一 个 时 间 范 围 。 


2.5 用例: 从 回调 API 到 0bservabtLe 流 


大 多 数 的 Java API 是 阻塞 式 的 ， 比 如 JDBC、java.io、Servlet ， 以 及 私有 的 解决 方案 。 这 意 
味 着 ,不 管 结果 或 副作用 是 什么 ， 客 户 端 线程 必须 要 等 待 。 但 是 ， 有 些 用 例 本 质 上 就 是 异 
步 的 ， 比 如 推送 来 自 外 部 源 的 事件 。 从 技术 上 来 讲 ， 你 可 以 按照 如 下 的 方式 构建 阻塞 式 的 
流 API。 














































































































while(true) { 
Event event = blockWaitingForNewEvent(); 
doSomethingWith(event); 


} 
如 果 某 个 领域 本 质 上 是 异步 的 ， 如 JavaScript， 你 很 可 能 会 发 现 某 种 基于 回调 的 API 非常 














注 1: Gregor Hohpe 和 Bobby Woolf 编著 的 《企业 集成 模式 设计、 构建 及 部 署 消息 传递 解决 方案 》。 
注 2: 至 少 直 到 3.0 版 本 。 
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常见 。 这 些 API 会 接收 某 种 形式 的 回调 ， 一 般 而 言 是 带 有 一 组 方法 的 接口 ， 从 而 实现 各 
种 事件 的 通知 。 几 乎 所 有 的 用 户 界面 都 是 这 种 API 的 典型 例子 ， 比 如 Swing。 在 使 用 像 
onClick() 或 onkeyUp() 这 样 的 监听 器 之 后 ， 回 调 就 难以 避免 了 。 如 果 你 曾经 经 历 过 这 样 的 






































环境 ， 那 么 你 对 回调 地 狱 (callback hell) 这 个 术语 肯定 不 会 感到 陌生 。 











回调 很 容易 互相 典 








套 ， 所 以 协调 多 个 回调 几乎 是 不 可 能 的 。 如 下 的 样 例 展现 了 回调 驱 套 4 层 的 场景 。 





button.setOnClickListener(view -> { 
MyApi.asyncRequest(response -> { 
Thread thread = new Thread(() -> { 
int year = datepicker .getYear(); 
runOnUiThread(() -> { 
button.setEnabled(false); 
button.setText("" + year); 
}); 
}); 
thread. setDaemon(true); 
thread. start(); 
]); 
]); 


在 以 上 的 代码 中 ， 即 便 是 最 简单 的 需求 都 将 是 一 场 于 梦 ， 比 如 要 在 两 个 回调 依次 调用 之 











后 做 出 反应 ,再 加 上 多 线程 的 阻碍 就 更 是 雪上 加 霜 了 。 本 市 会 将 基于 
RxJava， 它 具备 所 有 优点 ， 比 如 线程 控制 、 生 命 周期 管理 和 清理 。 














回调 的 API 重 构 为 





关于 流 ， 我 最 喜欢 的 一 个 例子 就 是 Twitter 的 状态 更 新 ， 也 就 是 所 谓 的 推 文 (tweet)。 每 秒 
都 会 有 数 千 个 用 户 更 新 ， 很 多 更 新 会 伴随 着 地 理 位 置 、 语 言 和 其 他 元 数据 。 为 了 完成 这 个 
练习 ， 将 会 使 用 开源 的 Twitter4J 库 ， 它 使 用 基于 回调 的 API 将 新 推 文 的 子 集 推送 过 来 。 本 





























章 的 目的 并 不 是 曾 述 Twitter4J 是 如 何 运 行 的 ， 也 不 会 提供 健壮 的 例子 
因为 它 是 使 用 回调 API 的 一 个 很 好 的 范例 ， 并 且 它 的 领域 非常 有 意思 。 
简单 的 可 运行 样 例如 下 所 示 。 


import twitter4j.Status; 

import twitter4j.StatusDeletionNotice; 
import twitter4j.StatusListener; 
import twitter4j.TwitterStream; 

import twitter4j.TwitterStreamFactory; 

















。 选 择 Twitter4J 是 


实时 读 取 推 文 的 最 


TwitterStream twitterStream = new TwitterStreamFactory().getInstance(); 


twitterStream.addListener(new twitter4j.StatusListener() { 
@Override 
public void onStatus(Status status) { 
log.info("Status: {}", status); 
} 


@Override 
public void onException(Exception ex) { 
Log.error("Error callback", ex); 


} 
// 其 他 回调 




















twitterStream.sample(); 

TimeUnit.SECONDS. sleep(10); 

twitterStream.shutdown(); 
调用 twitterstream.sample() 将 会 启动 一 个 后 台 线 程 ， 该 线程 会 登录 Twitter 并 等 待 新 的 消 
息 。 每 次 有 推 文 出 现 ，onStatus 回调 就 会 执行 。 执 行 过 程 可 能 会 跨 线程 ， 所 以 不 能 依赖 异 


常 抛 出 的 机 制 ， 而 是 使 用 onException() 通知 。 在 休眠 10 秒 之 后 ， 通 过 shutdown() 关闭 流 
并 清理 底层 的 资源 ， 比 如 HTTP 连接 或 线程 。 


整体 而 言 ， 它 看 上 去 并 没有 那么 糟糕 ， 这 个 程序 的 问题 在 于 什么 都 不 做 。 在 现实 生活 中 ， 
你 可 能 会 以 某 种 方式 处 理 每 条 Status 消息 (推广)， 比 如 保存 到 数据 库 中 或 者 提供 给 一 个 
机 器 学 习 算法 。 从 技术 上 来 讲 ， 你 可 以 将 这 些 逻 辑 放 到 回调 中 ， 但 是 这 样 就 将 基础 设施 调 
用 和 业务 逻辑 耦合 在 一 起 了 。 简 单 地 将 功能 委托 给 一 个 单独 的 类 会 更 好 一 些 ， 但 很 遗憾 的 
是 无 法 重用 。 我 们 真正 想 要 的 是 技术 领域 (消费 HTTP 连接 中 的 数据 ) 和 业务 领域 (解释 


输入 的 数据 ) 的 清晰 分 离 。 所 以 ， 我 们 构建 了 第 二 层 回 调 。 


void consume( 
Consumer<Status> onStatus, 
Consumer<Exception> onException) { 
TwitterStream twitterStream = new TwitterStreamFactory().getInstance(); 
twitterStream.addListener(new StatusListener() { 
@Override 
public void onStatus(Status status) { 
onStatus.accept(status); 
























































} 


@Override 
public void onException(Exception ex) { 
onException.accept(ex); 


} 


// 其 他 回调 
}); 


twitterStream.sample(); 








} 
通过 添加 这 个 额外 的 抽象 层 ， 现 在 能 够 以 各 种 方式 重用 consume() 方法 。 假 设 不 再 是 进行 
日 志 记 录 ， 而 是 要 进行 持久 化 、 分 析 或 欺诈 检测 。 


Consume( 
status -> log.info("Status: {}", status), 
ex -> log.error("Error callback", ex) 

















); 

但 是 这 只 将 问题 在 层级 结构 中 进行 了 提升 。 如 果 想 要 记录 每 秒 推 文 的 数量 该 怎么 办 ?或 者 
只 想 消费 前 5 条 数据 ， 又 该 怎样 实现 ?如果 想 要 有 多 个 监听 器 ， 又 会 发 生 什 么 情况 ?前 
述 每 种 情况 都 会 打开 一 个 新 的 HTTP 连接 。 最 后 不 得 不 提 的 是 ，API 不 允许 完成 后 再 取消 
订阅 ， 以 免 带 来 资源 泄漏 的 风险 。 希 望 你 能 意识 到 ， 我 们 正在 努力 朝 着 基于 Rx 的 API 的 
方向 努力 。 此 时 ， 不 再 传递 回调 到 可 能 要 执行 的 地 方 ， 而 是 返回 一 个 0bservabLe<Status> 
并 允许 每 人 按 需 对 其 进行 订阅 。 但 是 ， 需 要 记 住 的 一 点 是 ， 如 下 的 实现 还 是 会 为 每 个 
Subscriber 打开 一 个 新 的 网 络 连 接 。 
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Observable<Status> observe() { 
return Observable.create(subscriber -> { 

TwitterStream twitterStream = 
new TwitterStreamFactory().getIns 

twitterStream.addListener(new StatusL 
@Override 
public void onStatus(Status statu 

subscriber .onNext(status); 


} 


@Override 
public void onException(Exception 
subscriber .onError(ex); 


} 


// 其 他 回调 
}); 








tance(); 
istener() { 


s) { 


ex) { 


subscriber.add(Subscriptions.create(twitterStream: :shutdown) ) ; 


]); 
} 


此 时 ， 只 需 调用 observe()， 它 只 会 创建 一 个 Observable， 并 且 不 会 与 外 部 的 服务 器 联系 。 
create() 的 内 容 并 不 会 执行 ， 除 非 有 人 实际 订阅 。 订 阅 也 十 分 类 似 ， 如 下 所 示 。 


observe().subscribe( 





status -> log.info("Status: {}", status), 


ex -> log.error("Error callback", ex) 


9 


以 上 代码 与 consume(...) 的 巨大 差别 在 于 ， 不 必 将 
样 例 可 以 返回 0bservabtLe<Status>， 将 它 到 处 传递 ， 








回调 作为 参数 传递 给 observe()。 相 反 ， 
然后 在 某 个 地 方 进行 存储 ， 并 且 只 要 











需要 就 可 以 随时 随地 使 用 。 还 可 以 将 这 个 0bservable 与 其 他 的 Observable 进行 组 合 ， 这 
是 第 3 章 将 会 讲解 的 内 容 。 本 章 还 未 讨论 的 一 个 方面 是 资源 清理 。 有 人 取消 订阅 时 ， 应 当 
关闭 TwitterStream， 以 避免 资源 泄漏 。 我 们 已 经 知道 了 两 种 清理 技术 ， 下 面 首 先 使 用 稍 


微 简单 的 一 种 。 


@Override 
public void onStatus(Status status) { 
if (subscriber.isUnsubscribed()) { 
twitterStream.shutdown(); 
} else { 
subscriber .onNext(status ) ; 
} 
} 


@Override 
public void onException(Exception ex) { 
if (subscriber.isUnsubscribed()) { 
twitterStream.shutdown(); 
} else { 
subscriber .onError(ex); 
















































































如 果 有 人 进行 订阅 却 只 想得到 流 的 一 小 部 分 ，0bservable 会 确保 进行 资源 清理 
还 有 第 二 项 实现 清理 的 技术 ， 它 不 需要 等 待 上 游 的 事件 。 订 阅 者 取消 订阅 ， 检 
用 shutdown() 以 触发 清理 行为 (最 后 一 行 )， 而 不 必 等 待 下 一 条 推 文 到 达 。 
twitterStream.addListener(new StatusListener() { 
// 回 调 …… 
]); 


twitterStream.sample(); 


























subscriber.add(Subscriptions.create(twitterStream: :shutdown)); 


比较 有 意思 的 是 ， 这 个 0bservable 模糊 了 hot 流 和 cold 流 的 差异 。 一 方面 ， 


EE 。 我们 知道 
例 就 立即 调 


它 代表 了 外 





部 的 事件 ， 这 些 事件 的 出 现 并 不 受 控 制 (hot 流 的 行为 )。 另 一 方面 ， 实 际 订 阅 之 前 ， 事 
件 并 不 会 开始 流动 (没有 底层 的 HTTP 连接 )。 我 们 还 忽略 了 另外 一 个 不 慎 出 现 的 副 作 

















用 : 每 个 新 的 subscribe() 都 会 开启 一 个 新 的 后 台 线 程 和 一 条 到 外 部 系统 的 新 连接 。 相 





同 的 Observable<Status> 实例 应 该 能 够 跨 多 个 订阅 者 实现 重用 。 因 为 Observable 是 延 

















述 执行 的 ， 所 以 需要 在 技术 上 能 够 在 启动 的 时 候 就 调用 observe()， 并 将 其 











保留 在 其 个 





单 例 对 象 中 。 但 是 当前 的 实现 只 是 简单 地 打开 新 连接 ， 为 每 个 Subscriber 通过 网 络 多 次 
获取 相同 的 数据 。 当 然 ， 我 们 想 要 为 这 个 流 注册 多 个 Subscriber， 但 是 没有 理由 为 每 个 














Subscriber 都 独立 地 获取 相同 的 数据 。 我 们 真正 需要 的 是 一 种 发 布 - 订 阅 























pub-sub) 行 


为 ， 在 这 里 一 个 发 布 者 (外 部 系统 ) 投递 数据 给 多 个 Subscriber。 从 理论 上 讲 ，cache() 
操作 符 能 够 实现 这 一 点 ， 但 是 我 们 不 希望 永远 缓存 旧 的 事件 。 下 面 探讨 一 下 这 个 问题 的 一 

















些 解决 方案 。 


手动 管理 订阅 者 








手动 跟踪 所 有 的 订阅 者 ， 并 且 在 所 有 的 订阅 者 都 离开 时 关闭 对 外 部 系统 的 连接 ， 这 是 一 项 
没完 没 了 的 任务 ， 我 们 尝试 这 种 实现 方式 ， 仅 仅 是 为 了 更 好 地 阐述 后 文 的 惯用 方案 。 以 下 
代码 的 理念 就 是 以 Set<Subscriber<Status>> 的 某 种 形式 跟踪 所 有 的 订阅 者 ， 并 在 该 集合 为 


























空 / 非 空 的 时 候 关 闭 /打开 对 外 部 系统 的 连接 。 
// 不 要 这 样 做 ， 很 容易 出 错 


class LazyTwitterObservable { 








private final Set<Subscriber<? super Status>> subscribers = 
new CopyOnWriteArraySet<>(); 


private final TwitterStream twitterStream; 


public LazyTwitterObservable() { 
this.twitterStream = new TwitterStreamFactory().getInstance(); 
this.twitterStream.addListener(new StatusListener() { 
@Override 
public void onStatus(Status status) { 
subscribers.forEach(s -> s.onNext(status)); 


} 


@Override 
public void onException(Exception ex) { 
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} 


subscribers 的 集 线 程 安全 地 存储 当前 已 订阅 的 Observer 集合 。 每 次 新 的 Subscriber 出 


现 ， 将 其 


subscribers.forEach(s -> s.onError(ex)); 








// 其 他 回调 











private final Observable<Status> observable = Observable.create( 
subscriber -> { 
register(subscriber); 
subscriber .add(Subscriptions.create(() -> 
this.deregister(subscriber))); 


} 


Observable<Status> observe() { 
return observable; 


} 


private synchronized void register(Subscriber<? super Status> subscriber) { 
if (subscribers.isEmpty()) { 
subscribers.add(subscriber); 
twitterStream.sample(); 
} else { 
subscribers.add(subscriber); 
} 
} 


private synchronized void deregister(Subscriber<? super Status> subscriber) { 
subscribers.remove(subscriber); 
if (subscribers.isEmpty()) { 
twitterStream.shutdown(); 
} 
} 























添加 到 一 个 集中 ， 并 连接 到 底层 的 事件 源 上 。 相 反 ， 最 后 的 Subscriber 消失 时 ， 








器 关上 洲 的 庆 - 这 里 的 关键 在 于 始终 只 有 一 个 到 上 游 系 统 的 连接 ， 而 不 是 为 每 个 订阅 者 


都 建立 








连接 。 这 个 实现 能 够 正常 运行 而 且 比较 健壮 ， 但 看 起 来 过 于 低层 级 并 且 易 于 出 错 。 








对 subscribers 的 访问 必须 使 用 synchronized 同步 ， 而 且 和 集合 本 身 必须 支持 安全 地 迭代 。 
对 register() 的 调用 必须 发 生 在 通过 deregister() 注销 回调 之 前 ， 否 则 ， 后 者 可 能 会 在 


注册 之 


2.6 














前 调用 。 将 一 个 上 游 源 多 路 复 用 到 多 个 observer 的 通用 场景 ， 肯 定 有 更 好 的 方式 来 
实现 。 幸 而 ， 至 少 有 两 种 这 样 的 机 制 。RxJava 致力 于 减少 这 样 危险 的 样板 代码 并 抽象 出 并 











rx.subjects.Subject 


Subject 类 非常 有 意思 ， 它 扩展 了 0bservable， 同 时 还 实现 了 0bserver。 这 意味 着 既 可 以 


在 客户 家 


将 其 视 为 Observable (订阅 上 游 的 事件 )， 也 可 以 在 提供 者 端 将 其 视 为 0bserver 








(通过 调用 onNext() 按 需 往 下 游 推送 事件 )。 通 常情 况 下 ， 我 们 的 做 法 是 在 内 部 持 有 一 
个 对 Subject 的 引用 ， 这 样 就 可 以 从 任何 源 推 送 事 件 ， 而 对 外 则 将 该 Subject 暴露 为 
0bservable。 让 我 们 使 用 Subject 重新 实现 Status 流 的 更 新 。 为 了 进一步 简化 实现 ， 立 即 
连接 到 外 部 系统 并 且 不 再 跟踪 订阅 者 。 除 了 能 够 简化 样 例 之 外 ， 另 一 个 优点 就 是 能 够 减少 
第 一 个 subscriber 出 现时 的 延迟 。 如 下 所 示 ， 事 件 已 经 开始 流动 了 ， 所 以 不 需要 等 待 重新 
连接 到 第 三 方 应 用 程序 上 。 


class TwitterSubject { 





























private final PublishSubject<Status> subject = PublishSubject.create(); 


public TwitterSubject() { 
TwitterStream twitterStream = new TwitterStreamFactory().getInstance(); 
twitterStream.addListener(new StatusListener() { 
@Override 
public void onStatus(Status status) { 
subject.onNext(status); 


} 


@Override 
public void onException(Exception ex) { 
subject.onError(ex); 


} 


// 其 他 回调 
}); 


twitterStream.sample(); 


} 

















public Observable<Status> observe() { 
return subject; 


} 


} 
Publishsubject 是 Subject 的 子 类 之 一 ,会 立即 从 上 游 系统 接收 事件 ， 并 简单 地 将 它们 推 
送 (通过 调用 subject.onNext(...)) 至 所 有 的 Subscriber。Subject 内 部 会 跟踪 这 些 事 件 ， 
所 以 我 们 就 没有 必要 这 样 做 了 。 请 注意 ， 我 们 在 observe() 中 返回 了 subject， 假 装 其 为 简 
单 的 Observable。 如 果 有 人 订阅， 并 且 后 人 台 调 用 onNext() 之 后 ，Subscriber 会 立即 接收 到 
后 续 的 所 有 事件 至 少 在 它 取 消 订 阅 之 前 均 是 如 此 。Subject 在 内 部 管理 Subscriber 的 
生命 周期 ， 所 以 调用 onNext() 即 可 ， 无 须 关 心 有 多 少 订阅 者 在 监听 。 


Subject 中 的 错误 传播 


Subject 非常 有 用 ， 而 且 有 很 多 细节 需要 理解 。 例 如 ， 在 调用 subject.onError() 
之 后 ，Subject 会 悄 无 声息 地 丢弃 后 续 的 onError 通知 ， 实 际 上 就 是 将 其 吞 
吹 掉 了 。 








山 串 




















Observable.create(...) 看 上 去 过 于 复杂 、 难 以 管理 的 时 候 ，Subject 就 是 一 个 创建 Observable 
实例 的 有 用 工具 。 其 他 类 型 的 Subject 如 下 所 示 。 
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口 AsyncSubject 
记 住 发 布 的 最 后 一 个 值 ， 并 且 onComplete() 被 调用 时 ， 将 其 推送 给 所 有 的 订阅 者 。 如 
果 AsyncSubject 没有 完成 ， 除 了 最 后 一 个 事件 之 外 ， 所 有 的 事件 都 会 被 丢弃 。 

口 BehaviorSubject 

在 订阅 之 后 ， 将 所 有 发 布 的 事件 推送 给 订阅 者 ， 与 Publishsubject 类 似 。 但 是 ， 它 首 
先 会 发 布 在 订阅 之 前 发 生 的 最 新 事件 ， 从 而 让 Subscriber 立即 得 到 流 的 状态 。 比 如 ， 
Subject 可 能 会 代表 当前 的 温度 ， 每 分 钟 广播 一 次 。 从 客户 端 订阅 的 时 候 ， 他 将 立即 接 
收 到 最 新 的 可 见 温度 ， 而 不 用 等 待 几 秒 再 获得 下 一 个 事件 。 但 是 ， 同 一 个 Subscriber 
只 对 最 新 的 温度 感 兴 趣 ， 而 不 会 对 历史 温度 感 兴趣 。 如 果 此 时 还 没有 发 布 过 事件 ， 并 且 
提供 了 默认 事件 ， 那 么 将 会 首先 推送 一 个 特殊 的 默认 事件 。 

口 RepLaySubject 
最 有 意思 的 Subject 类 型 会 缓存 贯穿 整个 历史 的 推送 事件 。 如 果 有 人 订阅 ， 他 首先 
会 接收 到 一 批 被 错过 (缓存) 的 事件 ， 然 后 才 会 实时 接收 后 续 的 事件 。 默 认 情况 下 ， 
Subject 创建 之 后 的 所 有 事件 都 会 被 缓存 。 如 果 流 是 无 穷 的 或 者 非常 长 ， 这 可 能 会 非常 
危险 (参见 8.6 节 )。 在 这 种 情况 下 ， 可 以 使 用 重 载 版 本 的 ReplaySubject， 它 只 会 保留 
如 下 事件 。 


。 在 内 存 中 保留 可 配置 数量 的 事件 (createWithsize())。 
配置 最 近 事件 的 时 间 窗 口 (createwithTime())。 
。 通过 createWithTimeAndsize() 同时 限制 大 小 和 时 间 (限制 较 先 达到 的 条 件 )。 


Subject 要 非常 小 心地 使 用 : 通常 会 有 更 惯用 的 方式 来 共享 订阅 和 缓存 事件 ， 参 见 2.7 节 。 
目前 ， 应 该 优先 使 用 更 低级 的 Observable.create(), 或 者 考虑 标准 的 工厂 方法 ， 如 from() 
和 just()。 
另外 一 件 需 要 记 住 的 事情 是 并 发 。 默 认 情 况 下 ， 在 Subject 上 调用 onNext() 会 被 直接 传 
播 至 所 有 Observer 的 onNext() 回调 方法 。 这 些 方法 使 用 相同 的 名 字 并 不 奇怪 ， 从 某 种 意 
义 上 说 ， 在 Subject 上 调用 onNext() 会 间接 调用 所 有 Subscriber 的 onNext()。 但 是 ， 你 
需要 记 住 ， 按 照 Rx 设计 指南 ， 在 observer 上 对 onNext() 的 所 有 调用 必须 都 是 序列 化 的 
(也 就 是 串 行 )， 所 以 两 个 线程 不 能 同时 调用 onNext()。 但 是 ， 你 使 用 Subject 的 方式 ， 可 
能 很 容易 就 会 破坏 这 个 规则 ， 比 如 使 用 线程 地 中 的 多 个 线程 来 调用 Subject.onNext()。 才 
好 ， 如 果 你 担心 这 个 问题 ， 可 以 在 Subject 上 只 调用 .toserialized()， 它 类 似 于 调用 
Observable.serialize()。 这 个 操作 符 能 够 确保 下 游 的 事件 都 能 按照 正确 的 顺序 出 现 。 
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2.7 ConnectableObservable 


ConnectableObservable 以 一 种 有 意思 的 方式 来 协调 多 个 Subscriber， 并 共享 一 个 底层 的 订 
阅 。 还 记得 最 初 借助 LazyTwitterobservable 创建 单个 延迟 执行 的 对 底层 资源 的 连接 吗 ? 必 
须要 手动 跟踪 所 有 的 Subscriber ， 如 果 第 一 个 订阅 者 出 现 或 最 后 一 个 订阅 者 离开 ， 就 建立 连 
接 或 断 开 连接 。ConnectabLe0bservablLe 是 0bservable 的 一 个 特殊 类 型 ， 能 够 确保 底层 始终 
最 多 只 有 一 个 Subscriber ， 但 实际 上 它 又 允许 多 个 Subscriber 共享 相同 的 底层 资源 。 
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ConnectableObservable 有 很 多 应 用 场景 ， 例 如 : 不 管 Subscriber 何 时 订阅 ， 都 要 确保 
它们 接收 到 相同 的 事件 序列 。 如 果 订 阅 时 会 有 重要 的 副作用 ， 即 便 还 没有 “真正 ”的 
Subscriber ，ConnectableObservable 也 能 强迫 订阅 。 后 续 很 快 就 将 讨论 上 述 的 所 有 场景 。 
Subject 是 创建 Observable 的 必要 方式 ， 而 ConnectableObservable 会 保护 原始 的 上 游 
Observable， 并 确保 最 多 只 能 有 一 个 Subscriber 可 以 接触 到 它 。 不 管 有 多 少 Subscriber 连 
接 到 ConnectableObservable， 系 统 只 会 打开 一 个 Observable 的 订阅 ， 这 个 订阅 是 基于 该 
Observable 创建 的 。 


2.7.1 使 用 publish().refCcount() 实 现 单 次 订阅 


回顾 一 下 : 只 有 一 个 到 底层 资源 的 句柄 ， 如 到 Twitter 状态 更 新 流 的 HTTP 连接 。 但 是 ， 推 
送 事 件 的 这 个 Observable 将 会 被 多 个 Subscriber 共享 。 前 面 创建 的 Observable 的 原生 实 
现 并 没有 对 此 进行 控制 ， 因 此 每 个 Subscriber 会 启动 自己 的 连接 。 如 下 所 示 的 程序 代码 是 
非常 浪费 的 。 


Observable<Status> observable = Observable.create(subscriber -> { 
System.out.println("Establishing connection"); 
TwitterStream twitterStream = new TwitterStreamFactory().getInstance(); 
A 
subscriber.add(Subscriptions.create(() -> { 
System.out.println("Disconnecting"); 
twitterStream.shutdown(); 






































Ds 


twitterStream.sample(); 


}); 
尝试 使 用 这 个 0bservable 的 时 候 ， 每 个 Subscriber 都 会 建立 一 个 新 的 连接 ， 如 下 所 示 。 


Subscription sub1 = observable.subscribel(); 
System.out.println("Subscribed 1"); 
Subscription sub2 = observabLe.subscribe(); 
System.out.println("Subscribed 2"); 
sub1i.unsubscribe(); 
System.out.println("Unsubscribed 1"); 
sub2.unsubscribe(); 
System.out.println("Unsubscribed 2"); 


以 下 是 输出 。 


Establishing connection 
Subscribed 1 
Establishing connection 
Subscribed 2 
Disconnecting 
Unsubscribed 1 
Disconnecting 
Unsubscribed 2 


简单 起 见 ， 这 次 使 用 一 个 无 参数 的 subscribe()， 它 会 触发 订阅 ， 但 是 会 将 所 有 的 事件 和 通 
知 丢 弃 。 本 章 几乎 花费 了 一 半 的 篇 幅 来 解决 这 个 问题 ， 在 这 个 过 程 中 介绍 了 大 量 的 RxJava 
特性 。 最 后 我 们 介绍 一 个 最 具有 扩展 性 和 最 简单 的 解决 方案 : pubLitsh().refCount() 组 合 。 
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Lazy = observable.publish().refCount(); 
/hiss 

System.out.println("Before subscribers"); 
Subscription sub1 = lazy.subscribe(); 
System.out.println("Subscribed 1"); 
Subscription sub2 = lazy.subscribe(); 
System.out.printLn("Subscribed 2"); 
sub1.unsubscribe(); 
System.out.printLn("Unsubscribed 1"); 
sub2.unsubscribe(); 
System.out.printLn("Unsubscribed 2"); 


以 下 输出 与 预期 非常 相似 。 


Before subscribers 
Establishing connection 
Subscribed 1 

Subscribed 2 
Unsubscribed 1 
Disconnecting 
Unsubscribed 2 


直到 真正 有 第 一 个 Subscriber 的 时 候 ， 连 接 才 会 建立 。 但 是 ， 更 重要 的 在 于 ， 第 二 个 
Subscriber 不 会 初始 化 新 的 连接 ， 它 甚至 不 会 接触 到 原始 的 Observable。publish(). 
refCount() 会 将 底层 的 observabte 串联 包装 起 来 ， 并 拦截 所 有 的 订阅 。 稍 后 将 会 介绍 为 
何 需要 两 个 方法 ， 以 及 单独 使 用 publish() 意味 着 什么 。 暂 时 先 关 注 refCount()。 这 个 
操作 符 基 本 就 是 记录 此 刻 有 多 少 活跃 的 Subscriber， 非 常 类 似 于 历史 上 的 垃圾 - 收集 算 
法 。 这 个 数字 从 零 变 成 一 的 时 候 ， 它 会 订阅 上 游 的 0bservable。 所 有 超过 一 的 数字 都 会 被 
忽略 ， 同 一 个 上 游 Subscriber 就 被 所 有 的 下 游 Subscriber 共享 。 但 是 ， 如 果 最 后 一 个 下 
游 subscriber 取消 订阅 ， 计 数 器 将 会 从 一 减少 到 零 ，refcount() 就 知道 必须 马上 取消 订阅 
了 。refCount() 完全 做 到 了 通过 LazyTwitterObservable 手动 实现 的 功能 。 使 用 publish(). 
| Subscriber ， 同 时 依然 保持 延迟 执行 的 特征 。 这 对 操作 符 经 
第 同时 使 用 ， 因 此 有 了 一 个 别名 share()。 需 要 记 住 的 是 ， 如 果 订 阅 之 后 很 快 就 取消 订阅 ， 
share() 依然 会 执行 重新 连 ~ 就 像 没有 缓存 一 样 。 





























2.7.2 ”ConnectableObservable 的 生命 周期 


publish() 操作 符 另 外 一 个 有 效 的 用 例 就 是 在 没有 任何 Subscriber 的 情况 下 ， 强 制 进行 订 

阅 。 假 设 有 一 个 自己 的 0bservable<Status>， 在 将 它 暴 露 给 客户 端 之 前 ， 不 管 有 没有 人 订 

阅 ， 我 们 都 想 要 把 每 个 事件 存储 在 数据 库 中 。 如 下 所 示 ， 最 原始 的 方案 是 不 够 的 。 
Observable<Status> tweets = //... 


return tweets 
.doOnNext(this: :saveStatus); 


这 里 使 用 doonNext() 操作 符 ， 它 会 探查 经 过 流 的 每 一 个 条 目 并 执行 一 些 操 作 ， 比 如 
saveStatus()。 但 是 ， 不 要 忘记 ， 根据 设计 Observable 是 延迟 执行 的 因此 ， 如 果 没 有 人 
订阅 ，doonNext() 不 会 触发 。 这 里 想 要 的 是 一 个 假 的 Observer， 它 不 会 真正 地 监听 事件 ， 
但 是 能 够 强迫 上 游 的 Observable 生成 事件 。 一 个 重 载 版 本 的 subscribe() 就 可 以 完成 这 项 






































任务 ， 如 下 所 示 。 


Observable<Status> tweets = //... 
tweets 
.doOnNext(this: :saveStatus) 
.subscribe(); 


这 个 空 的 Subscriber 最 终 会 触发 0Observable.create()， 并 建立 到 上 游 事 件 源 的 连接 。 看 
上 去 ， 这 样 已 经 解决 了 这 个 问题 ,但 是 依然 无 法 解决 多 个 订阅 者 带 来 的 问题 。 如 果 将 
tweets 暴露 出 去 ， 第 二 个 订阅 者 将 会 尝试 发 起 对 外 部 资源 的 第 二 次 连接 ， 比 如 打开 第 二 个 
HTTP 连接 。 惯 用 的 解决 方案 是 组 合 使 用 publish().connect()， 它 们 会 立即 创建 一 个 人 工 
的 Subscriber ， 同 时 还 能 保持 只 有 一 个 上 游 的 Subscriber。 最 好 还 是 使 用 一 个 例子 来 进行 
阐述 。 最 后 ， 我 们 还 将 介绍 单独 的 publish() 是 如 何 运 行 的 ， 如 下 所 示 。 

ConnectableObservable<Status> published = tweets.publish(); 

published.connect(); 


最 终 ， 我 们 看 到 了 ConnectableObservable 的 所 有 功能 。 可 以 在 任意 0bservable 上 调用 
Observable.publish()， 并 有 旦 返回 一 个 ConnectableObservable。 在 这 里 ， 可 以 继续 使 用 
原始 的 上 游 observable (前 面 样 例 中 的 tweets)，publish() 并 不 会 影响 到 它 。 但 是 ， 现 
在 我 们 更 关注 返回 的 ConnectableObservable。 订 阅 ConnectableObservable 的 人 会 被 放 
到 一 个 Subscriber 集合 。 如 果 没 有 调用 connect()， 这 些 Subscriber 只 是 被 搁置 在 那里 ， 
它们 不 会 直接 订阅 上 游 的 Observable。 但 是 ， 如 果 调 用 了 connect()， 一 个 专用 的 中 间 
Subscriber 将 会 订阅 上 游 的 0bservable ( 即 tweets)， 不管 之 前 出 现 过 多 少 下 游 的 订阅 者 ， 
即便 没有 任何 的 下 游 订 阅 者 。 但 是 如 果 ConnectableObservable 的 一 些 Subscribe 搁置 了 ， 
那么 它们 都 会 接收 到 相同 序列 的 通知 。 


这 种 机 制 有 很 多 优势 。 假 设 在 应 用 中 有 一 个 Observable， 多 个 Subscriber 都 对 甚 感 兴趣 。 
在 启动 的 时 候 ， 会 有 多 个 组 件 〈 如 Spring bean 或 EJB) 订阅 该 0bservable 并 开始 监听 。 
如 果 没 有 ConnectableObservable，hot 类 型 的 Observable 开始 发 布 的 事件 很 可 能 只 能 由 第 
一 个 Subscriber 消费 ， 随 后 启动 的 Subscriber 会 丢失 早期 的 这 些 事件 。 如 果 你 希望 所 有 
的 Subscriber 收 到 系统 的 一 致 视图 ， 那 可 能 很 困难 。 所 有 的 Subscriber 都 会 以 相同 的 顺 
序 接收 到 事件 ， 但 是 晚 出 现 的 Subscriber 将 会 错失 早期 的 通知 。 


这 个 问题 的 解决 方案 就 是 先 将 这 个 Observable 通过 publish() 发 布 出 去 ， 这样 系统 中 
的 所 有 组 件 就 都 能 借助 subscribe() 进行 订阅 ， 比 如 在 系统 启动 的 过 程 中 完成 订阅 。 如 
果 100% 确定 需要 接收 相同 事件 序列 (包括 最 初 的 事件 ) 的 所 有 Subscriber 都 能 够 进行 
subscribe() 操作 了 ， 那 就 使 用 connect() 连接 ConnectabLe0bservabLe。 这 将 会 创建 一 个 
上 游 0bservablte 的 Subscriber， 并 将 事件 推送 给 所 有 下 游 的 Subscriber。 如 下 的 样 例 使 用 
了 Spring 框架 ， 但 代码 本 身 其 实 是 与 框架 无 关 的 。 

import org.springframework.context.ApplicationListener; 

import org.springframework.context.annotation.Bean; 

import org.springframework.context.annotation.Configuration; 

import org.springframework.context.event.ContextRefreshedEvent; 


import rx.Observable; 
import rx.observables.ConnectableObservable; 
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@Configuration 
class Config implements ApplicationListener<ContextRefreshedEvent> { 


private final ConnectabLe0bservabLe<Status> observable = 
Observable.<Status>create(subscriber -> { 
log.info("Starting"); 
/fs 
}) .publish(); 


QBean 
public Observable<Status> observable() { 
return observable; 


} 


@Override 

public void onApplicationEvent(ContextRefreshedEvent event) { 
log.info("Connecting"); 
observable.connect(); 


} 


@Component 
class Foo { 


@Autowired 
public Foo(Observable<Status> tweets) { 
tweets.subscribe(status -> { 
log.info(status.getText()); 


}); 
log.info("Subscribed"); 


} 


@Component 
class Bar { 


@Autowired 
public Bar(Observable<Status> tweets) { 
tweets.subscribe(status -> { 
log.info(status.getText()); 


}); 
log.info("Subscribed"); 


} 


这 个 简单 的 程序 首先 立即 创建 了 一 个 0Observable (底层 是 ConnectableObservable 子 类 )。 
按照 设计 ，0bservable 是 延迟 执行 的 ， 所 以 其 至 可 以 静态 地 创建 它们 。 这 个 0Observable 通 
过 publish() 进行 了 发 布 ， 所以， 在 进行 connect() 之 前 ， 所 有 后 续 的 Subscriber 都 会 被 
搁置 起 来 ， 不 会 收 到 任何 的 通知 。 随 后 ， 框 架 会 发 现 两 个 带 有 @Component 注解 的 组 件 ， 它 
们 需要 这 个 Observable。 依 赖 注入 框架 会 提供 ConnectableObservable 并 允许 任何 人 进行 
订阅 。 但 是 ， 在 程序 完整 启动 之 前 ， 事 件 也 不 会 出 现 ， 即 便 是 hot 类 型 的 Observable。 所 
有 的 组 件 都 实例 化 并 装配 完成 之 后 ， 可 以 消费 由 框架 发 送 的 ContextRefreshedEvent 事件 。 





























此 时 ， 可 以 确保 所 有 的 组 件 都 能 请 求 指 定 的 Observable， 并 且 通 过 subscribe() 订阅 。 程 





序 马上 启动 的 时 候 ， 调 用 connect()。 这 样 只 对 底层 0bservable 进行 一 次 订 








阅 ， 完 全 相同 


的 事件 序列 会 转发 给 每 个 组 件 。 裁 剪 之 后 的 日 志 输 出 如 下 所 示 ( 方 括号 中 对 应 的 是 组 件 的 





名 称 )。 
[Foo  ] Subscribed 
[Bar  ] Subscribed 


[Config] Connecting 
[Config] Starting 





[Foo ] Msg 1 
[Bar ] Msg 1 
[Foo  ] Msg2 
[Bar ] Msg 2 








注意 ，Foo 和 Bar 组 件 报告 了 它们 订阅 成 功 的 信息 ， 即 使 还 没有 收 到 任何 的 事件 。 
有 在 应 用 程序 完全 启动 之 后 ，connect() 才 会 订阅 底层 的 Observable 并 将 Msg 1 和 




















Msg 2 转发 给 所 有 的 组 件 。 相 同 场景 下 与 简单 Observable 进行 对 比 ， 














如 果 不 使 用 


ConnectableObservable， 并 人 允许 每 个 组 件 立 即 订 阅 ， 那 么 输出 可 能 会 如 下 所 示 。 





[Config] Starting 


[Foo  ] Subscribed 
[Foo ] Msg 1 
[Config] Starting 
[Bar  ] Subscribed 
[Foo  ] Msg2 

[Bar ] Msg 2 





这 里 有 两 个 差异 需要 注意 。 首 先 ，Foo 组 件 订阅 的 时 候 ， 它 会 立即 开启 一 个 
连接 ， 它 并 不 会 等 待 应 用 启动 完成 。 更 粳 糕 的 是 ，Bar 组 件 会 初始 化 另外 
Starting 出 现 了 两 次 )。 其 次 ，Bar 组 件 是 从 Msg 2 开始 的 ， 并 没有 收 到 Msg 
只 被 Foo 组 件 接收 到 了 。 消 费 hot 类 型 的 0bservabte 时 的 不 一 致 性 ， 在 有 些 
问题 ， 也 可 能 不 是 什么 问题 ， 但 是 你 必须 要 注意 。 


























2.8 小 结 
创建 和 订阅 0Observable 是 RxJava 的 重要 特性 。 尤 其 是 很 多 初学 者 会 忘记 订 





有 事件 发 布 出 来 感到 意外 。 很 多 开发 人 员 关 注 这 个 库 提 供 的 酷 炫 的 操作 符 ( 参 














到 底层 资源 的 
一 个 连接 (注意 


1, 这 条 信息 


场景 下 可 能 是 


阅 ， 于 是 对 没 
见 第 3 章 )， 


但 是 如 果 无 法 理解 这 些 操作 符 在 底层 如 何 执行 订阅 ， 将 会 导致 一 些微 妙 的 缺陷 。 


另外 ，RxJava 的 异步 特性 通常 被 认为 是 理所当然 的 ， eae ci ite 实际 上 ，RxJava 
中 的 大 多 数 操作 符 并 没有 使 用 任何 特殊 的 线程 池 。 更 确切 地 说 ， 这 意味 着 默认 情况 下 根本 
就 不 会 涉及 并 发 ， 所 有 的 操作 都 会 在 客户 端 线程 中 执行 。 0 另外 一 个 核心 要 点 。 现 















































在 ， 你 已 经 理解 了 订阅 和 并 发 原则 ， 能 够 更 加 轻松 和 高 效 地 使 用 RxJava 了 。 


第 3 章 将 介绍 如 何 使 用 这 个 库 提供 的 内 置 操 作 符 ， 以 及 如 何 将 它们 组 合 起 来 。 声 明 式 转换 


和 流 组 合 的 特性 让 RxJava 获得 了 空前 的 关注 。 
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第 3 章 


操作 符 与 转换 





托 马 什 : 努 尔 凯 维 茨 〈Tomasz Nurkiewicz) 


本 章 的 目标 在 于 阐述 RxJava 操作 符 (operator) 的 基础 知识 ， 以 及 如 何 组 合 它们 构建 高 
层级 、 易 于 理解 的 数据 管道 。RxJava 强大 的 一 个 原因 是 它 提供 了 丰富 的 内 置 操作 符 ， 并 
且 还 支持 自 定义 操作 符 。 操 作 符 是 一 个 函数 ， 它 接受 上 游 的 Observable<T> 并 为 下 游 返回 
Observable<R>， 这 里 的 类 型 T 和 R 可 能 相同 也 可 能 不 同 。 操 作 符 可 以 将 简单 的 转换 组 合 为 
复杂 的 处 理 图 。 


例如 ，0bservable.filter() 操作 符 从 上 游 的 Observabl 接受 条 目 ， 但 是 只 会 转发 匹配 指定 
断言 的 条 目 。 与 之 不 同 的 是 ，0bservabte.map() 会 转换 经 过 它 的 条 目 。 这 样 就 可 以 提取 、 填 
充 (enrich) 或 包装 原 有 的 事件 。 有 些 操 作 符 要 更 为 复杂 。 比 如 ，0bservable.delay() 会 原 
样 将 事件 传递 出 来 ， 但 是 在 一 个 固定 延迟 之 后 所 有 事件 才 会 出 现 。 最 后 ， 还 有 一 些 操作 符 
(如 Observable.buffer()) 可 能 以 成 批 处 理 的 方式 ， 在 消费 一 些 输 入 之 后 才 会 将 其 发 布 出 来 。 


你 也 许 已 经 意识 到 单个 Rx 操作 符 的 优势 ， 但 是 它 真 正 的 强大 之 处 在 于 组 合 。 链 接 多 个 操 
作 符 ， 将 流 分 成 多 个 子 流 ， 然 后 再 将 它们 联合 起 来 ， 这 是 习惯 性 的 做 法 。 经 过 这 一 章 的 学 
习 ， 你 应 该 能 够 对 此 驾轻就熟 。 


3.1 核心 的 操作 符 : 映射 和 过 滤 


操作 符 是 0bservable 典型 的 实例 方法 ， 它 会 按照 某 种 形式 变更 上 游 Observable 的 行为 ， 
下 游 的 Observable 或 Subscriber 看 到 的 是 变化 后 的 结果 。 这 听 上 去 可 能 有 些 复杂 ， 但 是 
它 实际 上 非常 灵活 ， 并 且 理 解 起 来 没有 那么 困难 。 操 作 符 的 最 简单 样 例 就 是 filter()， 它 
会 接受 一 个 断言 ， 事 件 要 么 能 够 通过 ， 要 么 会 被 丢弃 。 



















































































48 


Observable<String> strings = //... 
Observable<String> filtered = strings.filter(s -> s.startsWith("#")); 


现在 开始 介绍 所 谓 的 弹 珠 图 (marble diagram) ， 它 是 在 RxJava 中 普遍 存在 的 一 种 可 视 化 形 
式 。 弹 珠 图 阐述 了 各 种 操作 符 是 如 何 运 行 的 。 大 多 数 情 况 下 ， 你 会 看 到 两 个 水 平 轴 ， 代 表 
了 时 间 从 左 向 右 推移 。 图 中 的 形状 (前文 提 到 的 弹 珠 ) 对 事件 实现 了 可 视 化 。 上 面 的 轴线 
和 下 面 的 轴线 之 间 就 是 需要 讲解 的 操作 符 ， 该 操作 符 会 以 某 种 形式 改变 来 自 源 0bservable 
(上 游 ) 的 事件 序列 ， 并 形成 最 后 的 Observable (下 游 ) ， 如 图 3-1 所 示 。 




















这 是 由 0bservable 





这 是 0bservable 的 布 出 来 的 条 竖 线 代表 0bservabte 
向 右 推移 








这 些 虚 线 和 这 个 
0bservable 进 行 


转换 。 方 框 中 的 


中 中 文字 展示 了 转换 


这 个 Observable 

是 转换 后 的 结果 如 果 出 于 某 种 原因 ，0bservable 
非 正 常 终止 ， 出 现 错误 的 话 ， 

使 用 X 来 灰 代 坚 线 


























图 3-1 








图 3-2 展现 了 弹 珠 图 的 一 个 具体 样 例 ， 它 阐释 了 fitter() 操作 符 。0bservable.filter() 
返回 完全 相同 的 事件 〈 所 以 上 面 和 下 面 的 弹 珠 形状 完全 相同 )， 但 是 有 些 事件 因为 不 满足 
断言 被 过 滤 掉 了 。 
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图 3-2 
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在 处 理 特 定 类 型 的 0bservable 时 ， 你 可 能 对 某 些 事件 并 不 感 兴趣 ， 比 如 处 理 大 量 数据 。 对 同 
一 个 0bservable 进行 多 次 filter() 操作 也 是 常见 的 做 法 ， 每 次 过 滤 会 使 用 不 同 的 断言 。 我 
们 可 以 对 原始 的 0bservable 使 用 多 个 过 滤器 ， 甚 至 还 可 以 将 它们 链接 起 来 (filter(p1). 
filter(p2).filter(p3))， 从 而 实现 逻辑 联结 (filter(p1l && p2 &8& p3))。 将 多 个 操作 符 
(不 是 仅 适 用 于 filter()) 合并 为 一 个 既 有 优势 也 有 不 足 。 如 果 你 能 够 以 不 同 的 方式 重用 
更 小 的 转换 或 组 合 它 们 的 话 ， 那 么 推荐 使 用 更 小 的 转换 (如 多 次 过 滤 )。 而 另 一 方面 ， 更 
多 的 操作 符 会 增加 开销 和 栈 的 深度 。 选 择 哪 种 形式 取决 于 你 的 需求 和 代码 风格 。 

Observable<String> strings = someFileSource.lines(); 

Observable<String> comments = strings.filter(s -> s.startsWith("#")); 


Observable<String> instructions = strings.filter(s -> s.startsWith(">")); 
Observable<String> empty = strings.filter(String::isBlank); 


你 可 能 会 问 自己 这 样 一 个 问题 ， 上 游 的 原始 strings 源 发 生 了 什么 呢 ? 基于 面向 对 象 的 背 
景 ， 你 可 能 会 记得 像 java.util.List.sort() 这 样 的 方法 ， 它 会 在 List 内 部 对 条 目 进 行 重 
新 排序 ， 并 且 什 么 内 容 都 不 返回 。Java 的 List<T> 是 可 变 的 〈《 有 利 也 有 弊 ) ， 所 以 对 它 的 
内 容 进 行 重新 排序 是 可 以 的 。 类 似 地 ， 我 们 可 以 假想 一 个 void List.filter() 方法 ， 它 接 
受 一 个 断言 ， 在 内 部 移 除 不 匹配 的 元 素 。 在 RxJava 中 ， 你 必须 要 忘掉 内 部 可 变 的 数据 结 
构 : 在 流 之 外 修改 变量 通常 被 视 为 不 符合 常规 且 危 险 的 。 每 个 操作 符 都 要 返回 一 个 全 新 的 
Observable， 而 原 有 的 Observable 要 保持 不 变 。 
这 会 让 事件 流 的 原理 更 加 简单 。 你 可 以 将 一 个 流 分 成 多 个 独立 的 源 ， 每 个 源 都 具有 不 同 
的 特征 。RxJava 的 一 个 强大 之 处 在 于 ， 你 可 以 在 多 个 地 方 重用 同一 个 0bservable， 而 不 
会 影响 到 其 他 的 消费 者 。 如 果 你 将 0bservable 传递 给 一 个 未 知 的 函数 ， 你 可 以 确保 这 个 
0bservabte 不 会 被 该 函数 以 任何 方式 破坏 掉 。 对 于 可 变 的 java.util.Date， 你 无 法 做 出 这 
样 的 保证 ， 因 为 任何 引用 它 的 人 都 可 以 对 其 进行 修改 。 这 也 是 新 的 java.time API 完全 不 
可 变 的 原因 。 


3.1.1 使 用 map() 进 行 一 对 一 转换 

假设 有 一 个 用 事件 组 成 的 流 ， 你 必须 要 对 每 个 事件 进行 特定 的 转换 。 这 可 能 是 从 JSON 解 
码 为 Java 对 象 (反之 亦 然 )， 填 充 ， 包 装 ， 从 事件 中 进行 抽取 ， 等 等 。 这 就 是 重要 的 map() 
操作 符 能 够 发 挥 作 用 的 地 方 。 它 会 对 来 自 上 游 的 每 个 值 进 行 转换 ， 如 下 所 示 。 


import rx.functions.Func1; 

























































































Observable<Status> tweets = //... 
Observable<Date> dates = tweets.map(new Funci<Status, Date>() { 
@Override 
public Date call(Status status) { 
return status.getCreatedAt(); 
} 
}); 


























注 1: 正在 开展 操作 符 融 合 的 相关 研究 ， 期 望 将 多 个 操作 符 无 颖 合并 为 一 个 。 
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Observable<Date> dates = 
tweets .map((Status status) -> status.getCreatedAt() ) ; 


Observable<Date> dates = 
tweets .map((status) -> status.getCreatedAt()); 


Observable<Date> dates = 
tweets .map(Status: :getCreatedAt) ; 


定义 dates 0bservable 的 方式 其 实 都 是 等 价 的 ， 从 最 烦琐 的 Func1<T，R> 到 Java 8 语法 中 
最 紧凑 的 方法 引用 和 类 型 推断 。 但 是 ， 请 看 仔细 ! 名 为 tweets 的 原始 0bservable 生成 的 
是 Status 类 型 的 事件 。 随 后 ， 调 用 map()， 通 过 一 个 函数 将 单个 事件 (Status s) 转换 为 
Date 类 型 的 返回 值 。 顺 便 提 一 下 ， 可 变 事 件 (如 java.util.Date) 是 有 问题 的 ， 因 为 可 
变 事件 被 其 他 Subscribers 消费 时 ， 任 意 的 操作 符 或 Subscriber 都 可 能 无 意 间 改变 这 些 事 
件 。 可 以 使 用 后 续 的 map() 快速 修正 该 问题 ， 如 下 所 示 。 

Observable<Instant> instants = tweets 


.map(Status: :getCreatedAt) 
.map((Date d) -> d.toInstant()); 


map() 的 弹 珠 图 ， 如 图 3-3 所 示 。 





















































图 3-3 





map() 操作 符 接 收 一 个 函数 ， 该 函数 能 够 将 输入 事件 的 形状 从 圆 形 改 为 方形 。 这 种 转换 会 
应 用 到 流 经 的 每 个 条 目 上 。 
接 下 来 是 一 项 突击 测验 ， 确 保 你 真正 理解 了 0bservable 是 如 何 运行 的 。 观 察 如 下 代码 ， 然 
后 预测 一 下 0bservable 被 订阅 时 ， 将 会 发 布 出 什么 样 的 值 。 
Observable 
.just(8, 9, 10) 
.filter(i -> i%3 > 0) 


.map(i -> "#" + i * 10) 
.filter(s -> s.length() < 4); 


Observable 是 延迟 执行 的 ， 这 意味 着 只 在 有 人 订阅 的 情况 下 ， 它 们 才 会 产生 事件 。 你 可 以 


创建 一 个 无 穷 流 ， 耗 费 几 个 小 时 来 生成 第 一 个 值 。 但 是 ， 在 你 实际 表明 想 要 订阅 这 些 事件 
的 通知 之 前 ，0bservable 只 是 一 个 被 动 和 空闲 的 代表 T 类 型 的 数据 结构 。 这 种 情况 甚至 也 
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适用 hot 类 型 的 0bservable。 即 便 事件 源 在 不 断 地 生成 事件 ， 但 是 在 没有 人 真正 表示 感 兴 
趣 之 前 ， 像 map() 或 filter() 这 样 的 操作 符 都 不 会 被 执行 。 否 则 ， 哪 怕 运 行 所 有 的 计算 步 
又 并 将 结果 抛 出 来 ， 也 没有 任何 的 意义 。 每 次 使 用 操作 符 的 时 候 ， 包 括 本 书 还 未 介绍 的 那 
些 ， 实 际 上 就 是 围绕 着 原始 的 0bservable 创建 了 一 个 包装 器 。 这 个 包装 器 能 够 拦截 所 有 经 
过 的 事件 ， 但 是 它 本 身 并 不 会 进行 订阅 。 
Observable 

.just(8, 9, 10) 

.doOnNext(i -> System.out.println("A: " + i)) 

.filter(i ->i%3 > 0) 

.doOnNext(i -> System.out.println("B: " + i)) 

.map(i -> "#" + i * 10) 

.doOnNext(s -> System.out.println("C: " + s)) 

.filter(s -> s.length() < 4) 

.Subscribe(s -> System.out.println("D: " + s)); 


消息 经 过 流 时 ， 对 它们 进行 日 志 记 录 和 帘 探 是 非常 有 用 的 。 有 一 个 特殊 的 非 纯粹 (impure) 
的 操作 符 ， 名 为 doonNext()， 可 以 在 不 接触 这 些 条 目的 情况 下 对 其 进行 查看 。 说 它 不 纯粹 
是 因为 必须 要 依赖 于 副作用 ， 比 如 记录 日 志 或 访问 全 局 状态 。doonNext() 只 是 简单 地 接收 
来 自 上 游 observable 的 每 个 事件 并 将 其 传递 给 下 游 ， 它 不 能 以 任何 方式 对 事件 进行 修改 。 
doonNext() 类 似 一 个 探 针 ， 可 以 注入 0bservable 管道 的 任何 地 方 ， 从 而 观察 流 经 管道 的 
内 容 。 这 是 侦 听 (wiretap) 模式 的 简单 实现 ， 该 模式 可 以 在 Hohpe 和 Woolf 编著 的 《企业 
集成 模式 : 设计 、 构 建 及 部 署 消息 传递 解决 方案 》 中 找到 。 从 技术 上 讲 ，doonNext() 可 以 
对 事件 做 出 改变 。 但 是 ，0bservable 控制 的 可 变 事件 将 会 导致 灾难 性 的 后 果 。 你 很 快 将 会 
学 习 如 何 并 发 处 理事 件 ， 以 及 fork 执行 ， 等 等 。 保 证 每 个 事件 的 线程 安全 是 关键 。 根 据 经 
验 ， 对 于 所 有 实际 的 应 用 程序 ，0bservable 包装 的 所 有 类 型 都 应 该 是 不 可 变 的 。 

首先 ， 了 解 一 下 RxJava 的 执行 路 径 。 上 述 代码 样 例 中 的 每 一 行 都 会 通过 包装 原 有 的 
Observable 创建 一 个 新 的 Observable。 例 如 ， 第 一 个 filter() 并 不 会 从 0bservable. 
just(8，9，16) 中 将 9 移 除 ， 相 反 ， 它 会 创建 一 个 新 的 0bservable， 如 果 订 阅 这 个 新 的 
Observable， 最 终 发 布 的 值 是 8 和 10。 相 同 的 原则 适用 于 大 多 数 操作 符 ， 它们 不 会 修改 已 
有 0bservable 的 内 容 和 行为 ， 而 会 创建 新 的 Observable。 但 是 ,说 filter() 或 map() 只 
是 创建 新 的 Observable 有 点 太 简 略 了 。 大 多 数 的 操作 符 都 是 延迟 执行 的 ， 直 到 有 人 订阅 它 
们 才 会 执行 。 那 么 ，Rx 在 操作 链 的 末尾 看 到 subscribe() 会 发 生 些 什么 呢 ? 理解 内 部 能 够 
帮助 你 掌握 流 在 底层 是 如 何 进行 处 理 的 。 让 我 们 从 下 往 上 看 一 下 这 些 代码 。 


首先 ，subscribe() 通知 上 游 Observable 它 想 接收 值 。 

上 游 的 Observable (filter(s -> s.length() < 4)) 本 身 并 没有 任何 的 条 目 ， 它 只 是 转 
绕 男 一 个 Obervable 的 装饰 器 。 所 以 ， 它 也 会 订阅 上 游 的 流 。 

同 filter() 类 似 ，map(i -> "#" + ix 10) 本 身 并 不 会 投递 任何 的 条 目 ， 它 只 对 收 到 的 
任意 内 容 进行 转换 。 因 此 ， 它 必须 像 其 他 操作 符 那 样 订阅 上 游 的 流 。 

这 会 一 直 持 续 到 抵达 just(8，9，16)。 这 个 Observable 是 真正 的 事件 源 。filter(i -> 
i % 3 > 0) 订阅 它 的 时 候 (这 古 后 面 显 式 subscribe() 的 一 个 结果 )， 它 就 会 开始 为 下 
游 推 送 事件 。 









































































































































。 现在 ， 可 以 观察 一 下 事件 是 如 何 流 经 管道 中 的 所 有 阶段 的 。filter() 内 部 接收 到 8 并 将 
其 传递 到 下 游 (i % 3 > 6 断言 为 真 )。 随 后 ，map() 将 8 转换 为 字符 串 "#80"， 然 后 激 
活 它 下 面 的 filter() 操作 符 。 
断言 s.Length() < 4 同样 可 行 ， 然 后 可 以 将 转换 后 的 值 传递 给 System.out。 


doOnNex() 版 本 生成 的 输出 如 下 ， 你 可 以 花 些 时 间 研 究 一 下 9 和 16 是 如 何 从 结果 中 被 剔除 的 。 








门 四 二 口中 男 工 
\D 


3.1.2 ”使 用 flatMap() 进 行 包 装 


flatMap() 是 RxJava 中 最 重要 的 操作 符 之 一 。 乍 看 上 去 ， 它 类 似 于 map()， 但 是 它 对 每 个 
元 素 的 转换 都 会 返回 另外 一 个 (内 咀 的 ) 0bservable。 鉴 于 0bservable 可 以 代表 另外 一 
个 异步 操作 ， 我 们 很 快 就 意识 到 flatMap() 可 以 为 上 游 的 每 个 事件 执行 异步 计算 (fork 执 
行 ) 并 将 结果 加 入 进来 。 从 概念 上 讲 ，flatMap() 接收 一 个 Observable<T> 以 及 一 个 从 T 到 
Observable<R> 类 型 的 函数 。flatMap() 首先 会 构造 一 个 Observable<0bservable<R>>, 将 上 
游 7 类 型 的 值 禁 换 为 Observable<R> (与 map() 类 似 )。 但 是 ， 并 未 结束 ， 它 会 自动 订阅 
这 些 内 部 的 Observable<R> 流 ， 并 生成 一 个 R 类 型 的 流 ， 这 个 流 包含 了 所 有 内 部 流 的 值 。 
图 3-4 的 弹 珠 图 展现 了 它 是 如 何 运 行 的 。 






































flatMap { Cr-y> 一 > 人 } 











图 3-4 











上 面 的 弹 珠 图 涉及 了 flatMap() 的 一 个 重要 方面 。 每 个 上 游 的 事件 ( 圆 形 ) 会 转换 成 两 个 
菱形 组 成 的 Observable， 这 两 个 菱形 之 间 有 一 定 的 时 间 间 隔 。 如 果 两 个 上 游 事 件 出 现 的 时 
间 非 常 接近 ，flatMap() 会 自动 进行 转换 并 将 它们 变 成 两 个 菱形 的 流 。 但 是 ， 因 为 RxJava 
会 并 发 地 对 它们 进行 订阅 并 将 结果 合并 在 一 起 ， 所 以 某 个 内 部 0bservable 生成 的 事件 可 能 
会 与 其 他 0bservable 生成 的 事件 交叉 在 一 起 。 稍 后 会 探讨 这 种 行为 。 
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flatMap() 是 RxJava 最 基础 的 操作 符 之 一 ， 能 够 很 容易 地 “实现 map() 或 filter()。 


import static rx.Observable.empty; 
import static rx.Observable.just; 


numbers.map(x -> x * 2); 
numbers.filter(x -> x != 10); 


// 两 者 是 等 价 的 
numbers.flatMap(x -> just(x * 2)); 
numbers.flatMap(x -> (x != 10) ? just(x) : empty()); 


先 来 看 fLatMap() 的 一 个 更 实际 的 样 例 。 假 设 你 会 接收 到 汽车 进入 高 速 公路 的 一 系列 照片 。 
对 于 每 一 辆 汽车 ， 会 运行 一 个 代价 比较 高 的 光学 字符 识别 算法 ， 它 会 根据 汽车 的 牌照 返回 
相应 的 注册 号 码 。 显 然 ， 识 别 过 程 可 能 会 失败 ， 在 这 种 情况 下 ， 该 算法 将 不 会 返回 任何 内 
容 。 它 还 可 能 会 因为 异常 而 失败 ， 或 者 某 些 诡异 的 问题 造成 一 辆 车 返回 两 个 牌照 。 通 过 
Observable 可 以 很 容易 地 为 其 建 模 。 


Observable<CarPhoto> cars() { 


/1... 














} 


Observable<Licenseplate> recognize(CarPhoto photo) { 
AR 
} 


将 Observable<LicensePlate> 作为 基础 的 数据 流 ， 你 可 以 对 其 建 模 以 适应 如 下 场景 。 


。 在 照片 中 获取 不 到 牌照 ( 空 流 )。 

。 发 生 致 命 的 内 部 故障 (onError() 回调 )。 例 如 ， 识 别 模块 完全 地 、 永 久 地 失败 ， 而 且 没 
有 恢复 方案 。 

。 识别 出 一 个 或 多 个 牌照 ， 随 后 是 onComplete()。 

更 棒 的 是 ， 随 着 时 间 的 推移 ，recognize() 还 可 以 稳定 地 产生 更 好 的 效果 ， 比 如 从 粗略 佑 

计 或 并 发 运行 两 个 算法 开始 。 如 下 是 使 用 了 上 述 方 法 的 示例 代码 。 


Observable<CarPhoto> cars = cars(); 




















Observable<Observable<LicensePplate>> plates = 
cars.map(this::recognize); 


Observable<Licenseplate> plates2 = 
cars.flatMap(this::recognize); 


从 map() 函数 返回 的 内 容 会 再 被 包装 在 一 个 0bservable 中 。 这 意味 着 ， 如 果 你 返 
Observable<LicensepPlate> 的 话 ， 实 际 得 到 的 将 会 是 0bservabLe<0bservabLe<LicensePLate>>。 
一 个 Observable 舱 入 到 另 一 个 bbservabLe， 不 仅 使 用 起 来 非常 麻烦 ， 而 且 为 了 获取 结果 ， 
还 必须 首先 订阅 每 个 内 部 的 Observable。 除 此 之 外 ， 你 还 需要 以 某 种 方式 将 内 部 结果 同步 
到 一 个 流 中 ， 这 是 非常 困难 的 。 





回 















































注 2: 然而 考虑 到 性 能 ，RxJava 有 专用 的 map() 和 filter() 实现 。 
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flatMap() 通过 将 结果 扁平 化 (flattening) 解决 了 这 个 问题 ， 这 样 得 到 的 就 是 一 个 简单 的 
LicensePlate 流 。 除 此 之 外 ，4.9 节 将 会 介绍 如 何 使 用 flatMap() 运行 并 行 任务 。 一 般 可 以 
将 flatMap() 用 于 如 下 场景 。 


。 map() 转换 的 结果 必须 是 0bservable。 比 如 ， 对 流 中 的 每 个 元 素 执 行 长 时 间 运 行 的 异步 
操作 ， 这 些 操作 是 非 阻塞 的 。 
。 需要 进行 一 对 多 的 转换 ， 一 个 事件 要 被 扩展 为 多 个 子 事件 。 例 如 ， 客 户 组 成 的 流 要 被 转 
换 为 他 们 的 订单 组 成 的 流 ， 而 每 个 客户 可 能 会 有 任意 数量 的 订单 。 
现在 ， 假 设 你 想 要 使 用 一 个 返回 Iterable 〈 如 List 或 Set) 的 方法 。 例 如 ，Customer 有 一 
个 很 简单 的 List<0rder> getorders() 方法 ， 要 将 其 用 到 0bservable 管道 中 ， 必 须 通 过 一 
些 操作 符 ， 如 下 所 示 。 
Observable<Customer> customers = //... 
Observable<Order> orders = customers 


.flatMap(customer -> 
Observable.from(customer .getOrders())); 


或 者 使 用 如 下 的 等 价 形式 ， 不 过 依然 很 烦琐 。 


Observable<Order> orders = customers 
.map(Customer: :getOrders) 
.flatMap(Observable: :from); 


将 一 个 条 目 映射 到 Iterable 的 需求 非常 普遍 ， 因 此 RxJava 创建 了 一 个 专门 的 操作 符 
flatMapIterable() 来 执行 这 种 转换 ， 如 下 所 示 。 


Observable<Order> orders = customers 
.flatMapIterable(Customer::getOrders); 


简单 地 包装 0bservable 中 的 方法 时 ， 你 必须 非常 小 心 。 如 果 getorders() 并 不 是 一 个 简单 
的 getter 方法 ， 反 而 在 运行 时 间 方 面 代价 高 郧 ， 那 么 最 好 重新 实现 getorders()， 从 而 显 
式 返 回 Observable<Order>。 


fLatMap() 的 另外 一 个 变种 不 仅 能 够 对 事件 做 出 反应 ， 还 能 对 所 有 通知 做 出 反应 ， 也 就 
是 事件 、 错 误 通 知 和 完成 通知 。 随 后 ， 这 个 flatMap() 简化 签名 进行 重 载 。 对 于 每 个 
Observable<T>， 必 须要 提供 如 下 内 容 。 

。 有 映射 单个 T 一 0Observable<R> 的 函数 。 


。 映射 错误 通知 一 0bservabLe<R> 的 函数 。 
。 无 参 函 数 ， 响 应 上 游 的 完成 通知 并 能 够 返回 0bservable<R>。 


代码 如 下 所 示 。 


<R> Observable<R> flatMap( 
Func1<T, Observable<R>> onNext, 
Func1<ThrowabLe，0ObservabLe<R>> onError, 
Func0<0bservabLe<R>> onCompleted) 


假设 你 正在 创建 一 个 上 传 视频 的 服务 。 该 服务 接收 一 个 UUID， 并 通过 0bservable<Long> 返 
回 上 传 进度 ， 也 就 是 传输 了 多 少 字 节 。 可 以 按照 某 些 方式 使 用 这 个 进度 信息 ， 比 如 在 用 户 
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界面 对 其 进行 展现 。 但 是 ， 我 们 真正 关心 的 是 它 的 完成 信息 ， 也 就 是 上 传 何 时 最 终 完 成 。 
只 有 在 成 功 上 传 之 后 ， 才 能 对 视频 进行 评级 。 原 生 实 现 可 能 只 会 订阅 进度 流 ， 而 忽略 事件 
并 且 只 对 完成 通知 (最 后 一 个 回调 ) 进行 响应 ， 如 下 所 示 。 

void store(UUID id) { 


upload(id).subscribe( 


bytes -> {，// 忽 略 
e -> log.error("Error", e), 
() -> rate(id) 





























); 
} 


Observable<Long> upload(UUID id) { 
AR 
} 


Observable<Rating> rate(UUID id) { 
/fs 
} 


但 是 ， 需 要 注意 rate() 方法 实际 返回 的 Observable<Rating> 丢失 了 ， 而 我 们 真正 想 要 的 是 
store() 返回 第 二 个 Observable<Rating>。 不 过 ， 不 能 简单 地 并 发 调用 upload() 和 rate()。 
因为 如 果 前 者 尚未 完成 ， 后 者 将 会 失败 。 解 决 问题 的 答案 依然 是 fLatMap()， 不 过 要 使 用 
最 复杂 的 形式 。 
upload(id) 
.flatMap( 
bytes -> Observable.empty(), 


e -> Observable.error(e), 
() -> rate(id) 











); 


花 些 时 间 来 分 析 一 下 上 面 的 代码 。 这 里 有 一 个 uptoad() 方法 返回 得 到 的 0bservable 
<Long>。 对 于 Long 类 型 值 的 每 个 进度 更 新 ， 都 返回 0bservable.empty()， 实 际 上 也 就 是 
丢弃 了 这 些 事件 。 我 们 并 不 关心 进度 指示 器 的 值 ， 同 样 ， 也 不 关心 错误 信息 。 不 仅 不 记录 
错误 信息 ， 反 而 将 其 传递 给 订阅 者 。 需 要 注意 ， 原 生 方式 只 是 简单 地 记录 日 志 错 误 ， 实 际 
上 是 隐藏 了 它们 。 一 般 而 言 ， 如 果 不 知道 如 何 处 理 异 常 ， 那 么 就 让 你 的 监管 者 〈 如 调用 方 
法 、 父 任务 或 下 游 的 Observable) 来 做 出 决策 。 最 后 的 lambda 表达 式 (() -> rate(id)) 
会 对 流 的 完成 通知 做 出 反应 。 此 时 ， 将 完成 通知 替换 为 另外 一 个 Observable<Rating>。 
所 以 ， 即 便 原 始 的 0bservable 想 要 终止 ， 也 会 忽略 它 并 以 某 种 方式 生成 一 个 不 同 的 
0bservabLe。 需 要 注意 ， 这 三 个 回调 必须 返回 具有 相同 类 型 R 的 0bservabLe<R>。 


在 实践 中 ， 基 于 代码 清晰 性 和 性 能 方面 的 考虑 ， 并 不 会 使 用 flathap() 替换 map() 和 
filter()。 为 了 确保 你 已 经 理解 了 flathap() 的 语义 ， 以 下 是 另外 一 个 抽象 的 例子 ， 它 会 
将 一 个 字符 序列 转换 为 摩 斯 码 (morse code) 。 


import static rx.Observable.empty; 
import static rx.Observable.just; 
















































































Observable<Sound> toMorseCode(char ch) { 
switch(ch) { 
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case 'a': return just(DI, DAH); 
case 'b': return just(DAH, DI, DI, DI); 
case 'c': return just(DAH, DI, DAH, DI); 


AR 

case 'p': return just(DI, DAH, DAH, DI); 
case 'r': return just(DI, DAH, DI); 

case 's': return just(DI, DI, DI); 

case 't': return just(DAH); 

/fay 

default: 


return empty(); 
} 
} 


enum Sound { DI, DAH } 


11... 


just('S', 'p', 'a', 人 中 'a') 
.map(Character: :toLowerCase) 
.flatMap(this: :toMorseCode) 


你 可 以 清晰 地 看 到 ， 0 一 个 DI 和 DAH 声音 (点 和 划 线 ) 的 序列 。 如 果 
字符 无 法 识别 ， 将 会 返回 一 个 空 的 序列 。flatMap() 确保 E 够 得 到 一 个 稳定 、 ee 
音 流 。 A a map()， 得 到 的 则 是 0Observable<0bservable<Sound>>。 此 时 ， 涉 
及 flatMap() 的 一 个 重要 方面 ， 那 就 是 事件 的 顺序 。 这 最 好 通过 一 个 例子 来 进行 阐述 ， 如 
果 使 用 delay() 操作 符 ， 这 个 例子 可 能 会 更 有 意思 。 


3.1.3 ”使 用 delay() 操 作 符 延迟 事件 


delay() 操作 符 只 会 接收 上 游 的 0bservable， 并 在 一 定 的 时 间 后 发 布 所 有 的 事件 。 所 以 ， 
它 的 构造 很 简单 ， 如 下 所 示 。 


import java.util.concurrent.TimeUnit; 












































just(x, y, z).delay(1, TimeUnit.SECONDS); 
在 订阅 之 时 ， 它 并 不 会 立即 发 布 x、y 和 z， 而 是 在 给 定 延 迟 之 后 再 发 布 。 


第 2 章 已 经 介绍 了 timer() 操作 符 ， 它 们 非常 相似 。 可 以 使 用 timer() 和 flatMap() 来 禁 
代 delay()， 如 下 所 示 。 
Observable 

.timer(1, TimeUnit.SECONDS) 

.flatMap(i -> Observable.just(x, y, z)) 
以 上 代码 通过 timer() 生成 了 一 个 人 为 事件 ， 但 是 我 们 完全 忽略 掉 了。 然而 ,使 用 
flatMap() 将 这 个 人 为 事件 (也 就 是 i 值 中 保存 的 零 ) 禁 换 为 三 个 立即 发 布 的 值 x、y 和 z。 
在 这 个 特殊 场景 下 ， 可 以 说 这 与 just(x，y，z). ee SECONDS) 是 等 价 的 。 但 是 ， 一 般 
并 非 如 此 ，detay() 要 比 timer() 的 功能 更 加 强大 ， 会 将 每 个 事件 都 放 到 给 定 的 时 间 之 后 
再 发 布 出 来 ， 而 timer() 只 是 进行 “休眠 ”， 在 给 定 的 时 间 之 后 发 布 一 个 特定 的 事件 。 为 了 
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完整 ， 再 看 一 下 delay() 的 一 个 重 载 变种 形式 ， 它 会 计算 单个 事件 的 延迟 ， 而 不 是 全 局 所 有 
事件 。 如 下 代码 片段 会 延迟 每 个 String 值 的 发 布 ， 其 延迟 时 间 由 String 的 长 度 决定 。 


import static rx.Observable.timer; 
import static java.util.concurrent.TimeUnit.SECONDS; 
































Observable 
.just("Lorem", "ipsum", "dolor", "sit", "amet", 
"consectetur", "adipiscing", "elit") 
.delay(word -> timer(word.length(), SECONDS)) 
.Subscribe(System.out::println); 


TimeUnit.SECONDS. sleep(15); 
在 运行 这 个 程序 的 时 候 ， 即 便 进行 了 订阅 ， 应 用 程序 也 会 立即 终止 而 不 展现 任何 的 结果 ， 
这 是 因为 事件 的 发 布 是 在 后 台 运 行 的 。 第 4 章 将 会 介绍 Blocking0bservable， 它 会 让 这 样 
简单 的 测试 更 加 容易 。 但 是 ， 目 前 只 需要 在 最 后 添加 任意 一 个 sleep()。 你 会 发 现 ， 出 现 
的 第 一 个 单词 是 st，1 秒 后 ， 出 现 的 是 amet 和 elit。 还 记得 delay() 可 以 通过 timer() 和 
flatMap() 进行 重 写 吗 ? 你 可 以 自己 尝试 一 下 ， 解 决 方法 如 下 所 示 。 

Observable 

.just("Lorem", "ipsum", "dolor", "sit", "amet", 
"consectetur", "adipiscing", "elit") 


.flatMap(word -> 
timer(word.length(), SECONDS).map(x -> word)) 


上 述 样 例 暴露 了 flatMap() 一 个 很 有 意思 的 特点 : 它 并 不 能 保证 原始 事件 的 顺序 。 了 解 
delay() 如 何 运 行 之 后 ， 终 于 可 以 解决 这 个 问题 了 。 


3.1.4 flatMap() 之 后 的 事件 顺序 


从 本 质 上 来 讲 ，flatMap() 接收 一 个 随时 间 (事件 ) 出 现 的 值 的 主 (master) 序列 
(Observable)， 然 后 将 每 个 事件 分 别 禁 换 为 独立 的 子 序列 。 这 些 子 序列 彼此 之 间 是 不 相关 
的 ， 并且 与 生成 它们 的 主 序 列 中 的 事件 也 是 不 相关 的 。 更 确切 地 说 ， 此 时 拥有 的 不 再 是 单 
个 主 序列 ， 而 是 一 组 0bservable， 其 中 每 个 都 是 独立 运行 的 ， 并 且 随 着 时 间 的 推移 出 现 和 
消失 。 因 此 ，flatMap() 并 不 能 对 子 事件 抵达 下 游 操 作 符 / 订阅 者 的 顺序 给 出 任何 的 保证 。 
以 下 面 的 简单 代码 片段 为 例 。 
just(10L, 1L) 
.flatMap(x -> 
just(x).delay(x, TimeUnit.SECONDS)) 
.Subscribe(System.out::println); 
这 个 样 例 将 事件 16L 延迟 了 10 秒 ， 又 将 事件 1L (按时 间 顺 序 ， 在 上 游 的 流 中 它 是 稍 后 出 
现 的 事件 ) 延迟 了 1 秒 。 结 果 就 是 ， 会 在 1 秒 之 后 看 到 1， 并 且 再 过 9 秒 看 到 10 一 一 上 游 
和 下 游 事件 的 顺序 是 不 同 的 ! 更 糟糕 的 是 ， 假 设 一 个 flatMap() 转换 要 在 很 长 的 时 间 范 围 
内 生成 多 个 (其 至 是 无 穷 个 ) 事件 。 
Observable 


.just(DayOfWeek .SUNDAY, DayOfWeek .MONDAY) 
.flatMap(this: :loadRecordsFor); 
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loadRecordsFor() 方法 根据 星期 几 返 回 不 同 的 流 。 


Observable<String> loadRecordsFor(DayOfWeek dow) { 
switch(dow) { 
case SUNDAY: 
return Observable 
.interval(90, MILLISECONDS) 
.take(5) 
.map(i -> "Sun-" + i); 
case MONDAY: 
return Observable 
.interval(65, MILLISECONDS) 
.take(5) 
.map(i -> "Mon-" + i); 





/11... 
} 
} 


loadRecordsFor() 中 的 一 些 重复 是 有 意 为 之 : 提升 这 个 日 益 复 杂 的 样 例 的 可 读 性 。 尽 管 如 
此 ， 我 们 依然 会 逐步 学 习 这 个 flatMap()。 这 是 一 个 简单 的 Observable， 会 发 布 星期 几 的 
信息 : 星期 日 (Sunday) 之 后 马上 就 是 星期 一 (Monday)。 现 在 ,使 用 interval() 生成 的 
子 序列 对 这 些 值 进行 转换 。 快 速 提示 一 下 ，interval() 将 会 按照 固定 的 延迟 ， 从 零 开始 生 
成 不 断 递增 的 数字 。 样 例 中 的 延迟 取决 于 星期 几 ， 星期 日 (Sunday) 和 星期 一 (Monday) 
分 别 为 90 毫秒 和 65 毫秒。 每 个 序列 均 只 取 前 5 个 条 目 (take(5)， 参 见 3.2 节 )， 最 终 同 
时 得 到 了 两 个 Observable， 它 们 具有 不 同 的 频率 。 你 预期 得 到 的 输出 是 什么 呢 ?” 最 简单 直 
接 的 答案 可 能 如 下 所 示 。 


SuN-0, SuNn-1, SuN-2, SuN-3, SuNn-4, Mon-0, Mon-1, Mon-2, Mon-3, Mon-4 


实际 上 ， 你 有 两 个 独立 运行 的 流 ， 但 是 它们 的 结果 必须 以 某 种 形式 合并 (merge) 到 一 个 
Observable。flatMap() 遇 到 上 游 中 星期 日 (Sunday) 时 ， 它 会 立即 调用 LoadRecordsFor 
(Sunday)， 并 将 该 函数 结果 (0bservable<string>) 的 所 有 事件 转发 到 下 游 。 但 是 ， 儿 平 
与 此 同时 ， 星 期 一 (Monday) 会 出 现 ，flatMap() 将 会 调用 LoadRecordsFor(Monday)。 后 
面 的 子 流 产生 的 事件 也 会 被 传递 到 下 游 ， 与 第 一 个 子 流 产生 的 事件 会 交叉 在 一 起 。 如 
果 flatMap() 想 要 避免 重 全 ， 它 要 么 缓冲 所 有 后 续 的 子 0bservable， 直 到 第 一 个 子 
Observable 完成 ， 要 么 在 第 一 个 子 Observable 完成 之 后 ， 再 去 订阅 第 二 个 子 Observable。 
这 样 的 行为 其 实 已 经 在 concatMap() 中 实现 了 (参见 3.1.5 节 )。 但 是 ，flLatMap() 会 立即 订 
阅 所 有 的 子 流 并 将 它们 合并 到 一 起 ， 子 流 发 布 的 任何 事件 都 会 被 推送 至 下 游 。flatMap() 
返回 的 所 有 子 序 列 都 会 被 合并 ， 并 且 被 平等 对 待 ， 也 就 是 说 ，RxJava 立即 订阅 所 有 的 子 流 
并 将 事件 均匀 地 推送 到 下 游 之 中 。 


Mon-0, SuNn-0, Mon-1, Sun-1, Mon-2, Mon-3, Sun-2, Mon-4, Sun-3, Sun-4 


如 果 你 仔细 跟踪 所 有 延迟 ， 会 发 现 这 个 顺序 实际 是 正确 的 。 例 如 ， 虽 然 星 期 日 (Sunday) 
是 上 游 0bservable 中 的 第 一 个 事件 ， 但 Mon-6 事 件 是 第 一 个 出 现 的 ， 因 为 星期 一 
(Monday) 生成 的 子 流 发 布 速度 会 更 快 。 这 也 是 Mon-4 出 现在 Sun-3 和 Sun-4 之 前 的 原因 。 
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3.1.5 “使 用 concatMap() 保 证 顺序 


如 果 你 真 的 想 要 保持 下 游 事件 的 顺序 ， 使 其 与 上 游 事 件 的 顺序 完全 契合 ， 又 该 如 何 实现 
呢 ? 换 名 话说， 上 游 事件 N 产 生 的 下 游 事件 必须 发 生 在 N+1 产生 的 事件 之 前 。 这 里 就 涉及 
一 个 便捷 的 concatMap 操作 符 ， 它 和 flatMap() 语法 完全 一 样 ， 运 行 方式 却 非 常 不 同 ， 如 
下 所 示 。 

Observable 


.just(DayOfWeek .SUNDAY, DayOfWeek .MONDAY) 
.CconcatMap(this: :loadRecordsFor); 


现在 的 输出 完全 符合 预期 。 


SuN-0, SuNn-1, SuNn-2, SuN-3, SuNn-4, Mon-0, Mon-1, Mon-2, Mon-3, Mon-4 


那么 内 部 发 生 了 什么 呢 ?” 第 一 个 事件 (Sunday) 从 上 游 出 现 的 时 候 ，concatMap() 会 订阅 
LoadRecordsFor() 产生 的 Observable， 并 将 产生 的 所 有 事件 传递 到 下 游 。 这 个 内 部 流 完成 
时 ，concatMap() 会 等 待 下 一 个 上 游 事件 (Monday) 并 重复 以 上 过 程 。concatMap() 不 会 涉 
及 任何 的 并 发 性 ， 但 是 它 保 证 了 上 游 事件 的 顺序 ， 避 免 出 现 重 倒 。 


flatMap() 内 部 使 用 了 merge() 操作 符 ， 同 时 订阅 所 有 的 子 Observable， 对 
它们 不 做 任何 的 区 分 (参见 3.2.1 节 )。 这 也 是 下 游 事件 互相 交叉 的 原因 。 
但 是 ，concatMap() 可 以 在 技术 上 使 用 concat() 操作 符 (参见 3.4.1 节 )。 
concat() 只 会 先 订 阅 第 一 个 底层 的 bbservable， 只 有 第 一 个 完成 之 后 ， 才 会 
订阅 第 二 个 。 






































控制 flatMap() 的 并 发 性 
假设 你 有 大 量 用 户 的 一 个 列表 ， 它 们 被 包装 在 0bservable 中 。 每 个 User 有 一 个 
loadProfile() 方法 ， 该 方法 会 通过 HTTP 请 求 返 回 一 个 Observable<Profile> 实例 。 我 们 
的 目标 是 尽快 获取 所 有 用 户 概况 (profile)，flatMap() 就 是 为 了 实现 该 目标 而 设计 的 ， 可 
以 对 上 游 的 值 进行 并 发 计算 ， 如 下 所 示 。 

class User { 


Observable<Profile> LoadProfiLLe() { 
// 发 送 HTTP 请 求 …… 





} 
} 


class Profile {/* ... */} 


/11... 


List<User> veryLargelist = //... 

Observable<Profile> profiles = Observable 
.from(veryLargeList) 
.flatMap(User: :loadprofile); 


乍 看 上 去 这 种 方式 非常 不 错 。0bservable<User> 是 从 一 个 使 用 from() 操作 符 的 固定 List 
生成 的 。 因 此 ， 订 阅 它 的 时 候 ， 会 将 所 有 的 用 户 立 即 释 放出 来 。 对 于 每 个 新 User， 
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flatMap() 都 会 调用 loadProfile() 并 返回 0bservabLe<ProfiLe>。 然 后 ，fLatMap() 透明 
地 订阅 每 个 新 的 Observable<Profile>， 将 所 有 的 Profile 事件 转发 至 下 游 。 订 阅 内 部 
Observable<Profile> 就 相当 于 发 起 新 的 HTTP 连接 。 因 此 ， 假设 我 们 有 10 000 个 用 户 ， 
那 就 会 突然 发 起 10 000 个 并 发 的 HTTP 请 求 。 如 果 所 有 的 这 些 请 求 都 访问 相同 的 服务 器 ， 
预计 得 到 的 情况 无 外 乎 如 下 几 种 。 


拒绝 连接 。 
长 时 间 等 待 和 超时 。 
服务 器 停机 。 
遇 到 限 速 或 者 被 加 入 黑 名 单 。 
整体 的 延迟 增加 。 
客户 端的 问题 ， 包 括 太 多 打开 (open) 状态 的 Socket、 线 程 ， 以 及 过 多 的 内 存 消 耗 。 
增加 并 发 会 在 一 定 的 程度 上 得 到 回报 ,但 如 果 你 尝试 运行 太 多 并 发 操作 ， 最 终 将 会 导致 大 
量 的 上 下 文 切 换 、 过 高 的 内 存 和 CPU 占用 ， 以 及 整体 性 能 的 下 降 。 有 种 方案 是 在 一 定 程 
度 上 减缓 0bservable<User>， 这 样 的 话 ， 它 就 不 会 一 次 性 发 布 所 有 的 User。 但 是 ， 调 节 这 
个 延迟 以 实现 最 佳 的 并 发 级 别 是 非常 麻烦 的 。 相 反 ，flatMap() 有 一 个 非常 简单 的 重 载 形 
式 ， 能 够 限制 内 部 流 的 并 发 订阅 总 数 。 


flatMap(User: :loadprofile, 10); 


参数 maxConcurrent 限制 了 内 部 0bservable 的 订阅 数量 。 在 实践 中 ，flatMap() 接收 前 
10 个 User 时 ， 它 会 为 每 个 User 调用 loadProfile(), 但 是 来 自 上 游 的 第 11 个 User 出 现 
时 ，*flatMap() 不 会 再 调用 loadProfile()。 相 反 ， 它 会 等 正在 运行 的 内 部 流 完成 。 因 此 ， 
maxConcurrent 参数 限制 了 flatMap() 生成 的 后 台 任 务 的 数量 。 


你 可 能 已 经 发 现 ，concatMap(f) 在 语义 上 是 与 fLatMap(f，1) (也 就 是 maxConcurrent 值 为 
1 的 flLatMap()) 等 价 的 。 其 实 ， 本 来 还 可 以 多 用 几 页 的 篇 幅 介绍 flatMap()， 但 是 接 下 来 
还 有 更 有 意思 的 操作 符 。 


3.2 ”多 个 Observable 


转换 单个 Observable 是 非常 有 意思 的 ， 但 是 如 果 有 更 多 的 0bservable 需要 协作 又 该 怎么 
办 呢 ? 如 果 你 了 解 Java 中 传统 的 并 发 编程 ， 就 会 知道 代码 会 充斥 着 Thread 和 Executor， 
也 会 明白 共享 可 变 状 态 和 同步 是 多 么 困难 。 幸 而 ， 在 这 样 的 环境 中 ，RxJava 运行 得 会 更 
好 。 同 时 ， 该 库 还 有 一 个 统一 的 方式 来 处 理 错误 ， 涉 及 多 个 流 的 所 有 操作 符 均 能 使 用 这 种 
方式 。 如 果 上 游 的 任意 一 个 源 发 布 错误 通知 ， 它 将 会 被 传递 到 下 游 ， 并 且 以 一 个 错误 的 形 
式 完成 下 游 的 序列 。 如 果 多 个 上 游 的 observable 都 发 生 错误 ， 第 一 个 错误 将 会 优先 得 到 
处 理 ， 其 他 的 错误 则 会 被 舍弃 (每 个 0bservabte 只 能 发 布 一 次 onError， 参 见 2.1 节 )。 最 
后 ， 如 果 你 想 要 继续 进行 处 理 ， 并 且 等 所 有 正常 事件 都 得 到 处 理 之 后 再 去 发 布 错 误 ， 很 多 
操作 符 可 以 提供 *DelayError 的 变种 形式 。 

























































































































































































注 3: 事实 上 ，flatMap() 不 能 再 接收 User 了 ， 这 一 特性 将 在 6.2.4 节 中 详细 探讨 。 
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3.2.1 使 用 merge() 将 多 个 Observable 合 并 为 一 个 


还 记得 3.1.2 节 中 的 0bservabLe<LicensePLate> recognize(CarPhoto photo) 方法 吗 ? 这 个 
方法 会 异步 地 根据 CarPhoto 识别 LicensePlate。 我 们 曾经 简单 地 提 过 这 样 的 流 可 能 会 同时 
使 用 多 个 算法 ， 有 的 可 能 会 更 快 ， 有 的 可 能 会 更 精确 。 但 是 ， 我 们 并 不 想 将 这 些 细 市 暴露 
给 外 部 世界 ， 只 是 想 有 一 个 包含 渐进 式 优 化 结果 的 流 ， 这 个 结果 来 源 于 各 个 算法 ， 从 最 快 
的 到 最 精确 的 。 
假设 现在 有 三 个 支持 RxJava 的 算法 ， 每 个 算法 都 使 用 0bservable 进行 了 很 好 的 封装 。 当 
然 ， 每 个 算法 可 能 会 生成 零 个 到 无 穷 个 结果 。 
0bservabLe<LicensePLate> fastAlgo(CarPhoto photo) { 
// 速 度 快 但 质量 差 
































Observable<Licenseplate> preciseAlgo(CarPhoto photo) { 
// 精 确 但 代价 高 兄 
} 


0bservabLe<LicensePLate> experimentalAlgo(CarPhoto photo) { 


// 不 可 预测 ， 但 是 可 运行 














我 们 想 要 达到 的 效果 是 同时 运行 这 三 个 算法 (参见 4.9.2 市 ， 了 解 RxJava 处 理 并 发 的 更 多 
细节 ) 并 尽快 接收 结果 。 我 们 并 不 关心 是 哪个 算法 发 布 了 事件 ， 只 想 要 捕获 所 有 的 事件 并 
将 它们 聚集 到 一 个 流 中 。 这 就 是 merge() 操作 符 能 实现 的 功能 ， 如 下 所 示 。 
0bservabLe<LicensePLate> all = Observable.merge( 
preciseALgo(photo ) ， 


fastAlgo(photo), 
experimentalAlgo(photo) 











); 


以 上 代码 有 意 将 preciseAlgo()( 应 该 是 最 慢 的 一 个 ) 放 到 了 第 一 个 的 位 置 上 ， 以 强调 
传递 给 merge() 的 0bservable 顺序 是 任意 的 。merge() 操作 符 将 会 保留 一 个 对 所 有 底层 
Observable 的 引用 ， 有 人 订阅 Observable<LicensePlate> all 时 ， 它 会 一 次 性 地 订阅 所 有 
的 上 游 Observable。 不 管 是 哪个 Observable 首先 发 布 事件 ， 这 个 事件 都 将 会 转发 给 all 的 
Observer。 当 然 ，merge() 遵循 Rx 的 契约 (参见 2.1 节 )， 即 便 底 层 的 流 同 时 发 布 值 ， 它 也 
能 保证 事件 是 序列 化 的 (不 会 出 现 重 又)。 图 3-5 的 弹 珠 图 阐述 了 merge() 是 如 何 运 行 的 。 
merge( ) 操作 符 广泛 应 用 于 将 多 个 相同 类 型 的 事件 源 视 为 统一 来 源 的 情景 。' 同样 ， 如 果 你 想 
要 进行 merge() 的 Observable 只 有 两 个 ， 那 么 可 以 使 用 obs1.mergeWith(obs2) 实例 方法 。 
需要 注意 ， 任 何 底层 0bservable 出 现 的 错误 都 会 立即 传递 到 0bserver。 可 以 使 用 merge() 
的 mergeDelayError() 变种 形式 来 推迟 错误 ， 这 样 直 到 其 他 的 流 都 完成 ， 错 误 通 知 才 会 发 
布 。mergeDelayError() 甚至 能 够 保证 收集 所 有 的 异常 ， 而 不 仅仅 是 第 一 个 ， 并 将 它们 封装 


到 rx.exceptions.CompositeException, 












































注 4: 这 是 某 些 运算 类 型 的 联结 (join) 阶段 。 





入 后 
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图 3-5 


3.2.2 ”使 用 zip() 和 zipwith() 进 行 成 对 地 组 合 


压缩 (zipping) 指 的 是 将 两 个 (或 更 多 ) 流 组 合 起 来 的 操作 ， 在 这 个 过 程 中 ， 某 个 流 中 的 
每 个 事件 必须 要 与 其 他 流 对 应 的 事件 进行 成 对 组 合 。 下 游 事件 是 通过 组 合 每 个 流 中 的 第 一 
个 事件 ， 然 后 再 组 合 第 二 个 事件 ， 以 此 类 推 生成 的 。 因 此 ， 当 所 有 的 上 游 源 都 发 布 事 件 
时 ， 才 会 出 现 事 件 。 如 有 果 想 以 某 种 形式 组 合 多 个 彼此 相关 的 流 的 结果 ， 这 个 操作 符 是 很 有 
用 的 。 或 者 与 之 相反 ， 两 个 独立 的 流 各 自发 布 值 ， 但 是 只 有 将 它们 组 合 在 一 起 才 有 业务 含 
义 。 图 3-6 的 弹 珠 图 前 述 了 它 是 如 何 运 行 的 。 



























































-OO 一 个 一 六- 二 


zip() 和 zipWith() 操作 符 是 等 价 的 。 如 果 想 要 流畅 地 将 一 个 流 与 另 一 个 流 进行 组 合 ， 就 可 
以 使 用 后 者 ， 比 如 si.zipwith(s2，...)。 但 是 ， 如 果 想 要 组 合 的 流 超 过 了 两 个 ， 那 么 可 以 
使 用 0bservable 静态 的 zip()， 它 最 多 接收 9 个 流 。 


Observable.zip(s1, s2, s3...) 











图 3-6 
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很 多 其 他 的 操作 符 都 有 实例 方法 和 静态 方法 的 变种 ， 比 如 merge() 和 mergeWith()。 为 了 理 
解 zip()， 假设 有 两 个 独立 的 流 ， 而 这 两 个 流 是 完全 同步 的 。 例 如 ，Weatherstation 的 API 
每 分 钟 都 要 同时 精准 地 发 布 温度 和 风力 信息 ， 如 下 所 示 。 
interface WeatherStation { 
Observable<Temperature> temperature( ) ; 


Observable<Wind> wind(); 


} 


样 例 必须 要 假设 这 两 个 0bservable 中 的 事件 是 同时 发 布 的 ， 也 就 是 具有 相同 的 频率 。 基 于 
这 个 限制 ， 可 以 很 安全 地 将 事件 成 对 组 合 在 一 起 ， 从 而 实现 这 两 个 流 的 合并 。 这 意味 着 ， 
某 个 流 上 出 现 事件 时 ， 必 须 将 其 临时 持 有 ， 直 到 另 一 个 事件 出 现 ， 反 之 亦 然 。 术 语 zip 意 
味 着 要 将 两 个 流 的 事件 联结 在 一 起 ， 一 个 来 自 左 侧 ， 一 个 来 自 右 侧 ,循环 重复 。 但 是 ,在 
更 通用 的 版 本 中 ，zip() 最 多 能 够 接收 9 个 上 游 0bservable， 并 且 只 有 它们 全 部 发 布 事件 
的 时 候 ， 才 会 形成 下 游 的 事件 。 

zip() 最 合适 的 返回 类 型 似乎 是 元 组 (tuple) 或 结对 (pair， 两 个 元 素 的 元 组 )。 但 遗憾 的 
是 ，Java 并 没有 针对 结对 的 内 置 数据 结构 ， 而 RxJava 本 身 也 没有 任何 的 外 部 依赖 。 可 以 
使 用 来 自 Apache Commons Lang、Javaslang 或 Android SDK 的 Pair 实现 。 或 者 也 可 以 提 
供 组 合成 对 事件 的 函数 或 数据 结构 ， 如 下 所 示 。 


class Weather { 
public Weather(Temperature temperature, Wind wind) { 


/11... 






































} 
} 


/1... 


Observable<Temperature> temperatureMeasurements = station.temperature(); 
Observable<Wind> windMeasurements = station.wind(); 


temperatureMeasurements 
.ZipWith(windMeasurements, 
(temperature, wind) -> new Weather(temperature, wind)); 


新 的 Temperature 事件 出 现时 ，zipwith() 会 等 待 Wind (当然 是 没有 阻塞 的 )， 反 之 亦 
然 。 这 两 个 事件 会 传递 到 自 定义 的 lambda 中， 并 组 合成 一 个 Weather 对 象 。 然 后 ， 循 环 
往复 该 过 程 。zip() 是 使 用 流 的 方式 来 进行 描述 的 ， 其 至 是 无 穷 流 。 但 是 ， 你 会 发 现 为 
Observable 使 用 zipwith() 和 zip() 通常 只 会 发 布 一 个 条 目 。 这 样 的 Observable 一 般 是 对 
某 种 请 求 或 操作 的 异步 响应 。 第 4 章 将 会 讨论 如 何 将 RxJava 用 到 真正 的 应 用 中 。 
现在 学 习 一 个 样 例 ， 根 据 两 个 流 中 的 所 有 值 生成 笛 卡 儿 积 。 例 如 ， 可 能 有 两 个 Observable， 

个 代表 棋盘 的 行 (rank， 从 1 到 8)， 另 一 个 代表 棋盘 的 列 (fle， 从 a 到 hh)。 应 该 能 够 
找到 棋盘 上 所 有 64 个 可 能 的 方 格 。 


Observable<Integer> oneToEight = Observable.range(1, 8); 
Observable<String> ranks = oneToEight 



































注 5; 简短 的 lambda 语法 Weather: :new 在 这 里 也 适用 。 
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.map(Object: :toString); 
Observable<String> files = oneToEight 

.map(x -> 'a' + Xx - 1) 

.map(ascii -> (char)ascii.intValue()) 

.map(ch -> Character.toString(ch)); 


Observable<String> squares = files 
.flatMap(file -> ranks.map(rank -> file + rank)); 


Observable 将 会 精确 地 发 布 64 个 事件 : 针对 a 它 会 生成 al、a2...a8， 然 后 是 bl1、b2 等 ， 
直到 最 后 达到 h7 和 h8。 这 是 flatMap() 另 一 个 非常 有 意思 的 样 例 ， 每 列 (file) 都 会 生成 该 
列 对 应 的 所 有 可 能 的 方 格 。 现 在 ， 来 看 一 个 更 现实 的 例子 ， 它 也 会 用 到 第 卡 儿 积 。 假 设 你 想 
要 规划 在 某 个 城市 的 一 日 游行 程 ， 但 是 只 有 天 气 晴 朗 并 且 有 廉价 航班 和 酒店 的 时 候 ， 该 旅游 
行程 才 有 效 。 为 了 实现 这 一 点 ， 需 要 将 多 个 流 联合 在 一 起 并 形成 所 有 可 能 出 现 的 结果 。 


import java.time.LocalDate; 














Observable<LocalDate> nextTenDays = 
Observable 
.range(1, 10) 
.map(i -> LocalDate.now().plusDays(i)); 


Observable<Vacation> possibleVacations = Observable 

.just(City.Warsaw, City.London, City.Paris) 

.flatMap(city -> nextTenDays.map(date -> new Vacation(city, date)) 

.flatMap(vacation -> 

Observable.zip( 

vacation.weather().filter(Weather::isSunny), 
vacation.cheapFlightFrom(City.NewYork), 
vacation.cheapHotel(), 
(w, f, h) -> vacation 


)); 
Vacation 类 如 下 所 示 。 


class Vacation { 
private final City where; 
private final LocalDate when; 


Vacation(City where, LocalDate when) { 
this .where = where; 
this .when = when; 


} 


public Observable<Weather> weather() { 
A 
} 


public Observable<Flight> cheapFlightFrom(City from) { 
AR 
} 


public Observable<Hotel> cheapHotel() { 
/sa 
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} 
} 

在 上 面 的 代码 中 发 生 了 很 多 事情 。 首 先 ， 组合 使 用 range() 和 map() 生成 从 明天 开始 往 后 
10 天 的 日 期 。 然 后 ， 使 用 flatMap() 与 三 个 城市 进行 组 合 ， 在 这 里 我 们 不 想 使 用 zip()， 
因为 需要 得 到 日 期 与 城市 所 有 可 能 的 组 合 。 对 于 每 个 组 合 ， 创 建 一 个 Vacation 实例 来 封装 
它 。 现 在 到 了 真正 的 逻辑 ， 使 用 zip 操作 符 连 接 三 个 Observable: 0bservable<Weather>、 
Observable<Flight> 和 0bservable<Hotel>。 根 据 指 定 的 城市 /日 期 是 否 有 廉价 的 航班 和 
酒店 ， 后 两 个 Observable 将 会 返回 零 个 或 一 个 结果 。 尽 管 Observable<Weather> 始终 都 会 
返回 结果 ， 但 是 我 们 使 用 filter(Weather::sunny) 丢弃 非 睛 朗 的 天 气 。 最 后 会 对 这 三 个 
流 进行 zip() 操作 ， 每 个 流 会 发 布 零 到 一 个 条 目 。 如 果 任 意 一 个 上 游 的 Observable 完成 ， 
zip() 就 会 立即 完成 并 马上 丢弃 其 他 的 流 。 由 于 这 一 特性 ， 如 果 天 气 、 航 班 或 酒店 中 的 任 
意 一 个 0bservable 不 存在 ， 马 上 就 会 生成 zip() 的 结果 ， 这 种 情况 下 没有 条 目 发 布 。 这 样 
形成 了 一 个 流 ， 它 由 所 有 满足 需求 的 行程 组 成 。 

不 要 惊讶 于 zip 函数 根本 不 考虑 参数 : (w，f，h) -> vacation。 外 层 的 Vacation 流 列 出 了 
每 天 所 有 可 行 的 行程 。 但 是 ， 我 们 想 要 确保 每 个 行程 都 出 现 天 气 、 廉 价 航 班 和 酒店 信息 。 
如 果 所 有 的 条 件 都 满足 ， 就 会 返回 一 个 vacation 实例 ， 否 则 ，zitp 根本 就 不 会 调用 lambda 





























3.2.3” 流 之 间 不 同步 的 情况 : combineLatest()、withLatest- 
From() 和 amb() 

3.2.2 市 做 了 一 个 非常 大 胆 的 假设 ， 即 假设 两 个 0bservable 始终 以 相同 的 频率 且 在 比较 接 

近 的 时 间 点 生成 事件 。 但 是 ， 如 果 其 中 一 个 流 的 性 能 要 比 另 一 个 流 略 好 一 些 ， 那 么 较 快 

Observable 生成 的 事件 需要 花费 越 来 越 多 的 时 间 等 待 较 慢 流 的 事件 。 为 了 阐述 这 一 点 ， 首 

先 对 两 个 流 进行 zip() 操作 ， 这 两 个 流 按 照 完 全 相同 的 频率 生成 条 目 。 


Observable<Long> red = Observable.interval(10, TimeUnit.MILLISECONDS); 
Observable<Long> green = Observable.interval(10, TimeUnit.MILLISECONDS); 























Observable.zip( 
red.timestamp(), 
green.timestamp(), 
(r, g) -> r.getTimestampMillis() - g.getTimestampMillis() 
) .forEach(System.out: :println); 
red 和 green 这 两 个 Observable 按照 相同 的 频率 生成 条 目 。 为 每 个 条 目 附加 上 timestamp() 
信息 ， 这 样 就 能 知道 发 布 的 时 间 。 


timestamp() 


timestamp() 操作 符 使 用 rx.schedulers.Timestamped<T> 类 包装 任意 T 类 型 的 
事件 ， 这 个 类 有 两 个 属性 : 一 个 是 原始 的 T 类 型 的 值 ， 另 一 个 是 创建 它 时 的 
Long 时 间 戳 。 

















上 面 的 zip() 转换 只 是 简单 地 对 比 了 两 个 流 中 每 个 事件 的 创建 时 间 。 如 果 流 是 同步 的 ， 那 
么 这 个 值 大 约 等 于 零 。 但 是 ， 如 果 稍 微 降 低 其 中 一 个 Observable 的 速度 ， 假 设 把 green 修 
改 为 Observable.interval(11,MILLISECONDS)， 情 况 将 会 大 不 相同 。red 和 green 的 时 间 差 
将 会 越 来 越 大 : red 能 够 被 实时 消费 ， 但 是 它 必须 要 等 待 。 因 为 另外 一 个 条 目 产 生得 更 慢 ， 
这 会 增加 消耗 的 时 间 。 随 着 时 间 的 推移 ， 这 种 差异 会 累积 起 来 ， 产 生 过 期 数据 ， 其 至 内 存 
泄漏 (参见 8.6 节 )。 在 实践 中 ， 使 用 zip() 必须 要 非常 小 心 。 


我 们 真正 想 要 的 效果 是 任意 一 个 上 游 流 产生 事件 时 ， 就 使 用 另外 一 个 流 最 新 的 已 知 值 。 这 
就 是 combineLatest() 能 够 发 挥 作用 的 地 方 了 ， 如 图 3-7 的 弹 珠 图 所 示 。 













































































图 3-7 


参考 以 下 样 例 。 一 个 流 每 隔 17 毫秒 就 会 产生 S9、S1、S2...;， 而 另 一 个 流 每 隔 10 毫秒 会 
产生 F6、F1、F2... (更 快 一 些 )。 


import static java.util.concurrent.TimeUnit.MILLISECONDS; 
import static rx.Observable.interval; 


Observable.combineLatest( 
interval(17, MILLISECONDS).map(x -> "S" + X)， 
interval(10, MILLISECONDS).map(x -> "F" + X)， 
(s, f) ->f+":"+Ss 

).forEach(System.out: :println); 


将 这 两 个 流 组 合 在 一 起 ， 其 中 任意 一 个 流 生成 事件 时 都 会 产生 一 个 新 的 值 。 输 出 很 快 就 会 
不 同步 了 ,但 至 少 此 时 值 能 够 实时 被 消费 掉 ， 较 快 的 流 不 用 再 等 待 较 慢 的 流 。 
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F998:S586 
F998:S587 
F999:S587 
F1000:S587 
F1000:S588 
F1001:S588 


请 注意 ， 每 个 新 F 事件 上 的 新 条 目 是 如 何在 下 游 中 出 现 的 : F0:S9、F1:S9 和 F2:50。 
RxJava 在 较 快 的 流 上 发 现 了 新 事件 ， 所 以 它 就 从 较 慢 的 流 上 得 到 最 新 的 一 个 值 ( 较 快 的 流 
依然 有 两 个 事件 在 等 待 较 慢 的 流 上 的 一 个 事件 )， 在 这 里 也 就 是 56， 并 生成 一 个 新 的 值 对 。 
但 是 ， 具 体 哪个 流 是 没有 区 别 的 : 较 慢 流出 现 S1 时 ， 同 样 会 取 到 较 快 流 上 最 新 的 值 (F2) 
并 将 其 联合 起 来 。 大 约 10 秒 之 后 ， 我 们 就 会 看 到 F1090:5588。 所 有 的 事件 累加 在 一 起 : 
在 这 10 秒 的 时 间 里 ， 较 快 的 流 生 成 了 大 约 1000 个 事件 ， 而 较 慢 的 流 只 生成 了 588 个 (也 
就 是 用 10 秒 除 以 17 毫秒 得 到 的 结果 )。 
1. withLatestFrom( ) 操 作 符 
combineLatest 是 对 称 的 ， 也 就 是 说 它 不 会 区 分 想 要 组 合 的 子 流 。 但 在 有 些 情况 下 ， 可 以 在 
某 个 流出 现 事件 的 时 候 ， 结 合 第 二 个 流 中 的 最 新 值 生成 一 个 事件 ， 反 之 则 不 可 以 。 换 句 话 
说 , 来自 第 二 个 流 的 事件 并 不 会 触发 下 游 的 事件 ， 只 有 第 一 个 流 发 布 事件 的 时 候 才 会 用 到 
它们 。 可 以 使 用 新 的 withLatestFrom() 操作 符 来 实现 这 一 行为 。 下 面 使 用 相同 的 slow 和 
fast 流 来 阐述 。 

Observable<String> fast = interval(10, MILLISECONDS).map(x -> "F" + X); 

Observable<String> slow = interval(17, MILLISECONDS).map(x -> "S" + XxX); 

slow 


.withLatestFrom(fast, (s, f) -> s+":" + f) 
.forEach(System.out: :println); 


在 上 面 的 样 例 中 ，slow 流 是 主导 性 的 ，slow 发 布 事件 的 时 候 ， 最 终 的 0bservable 始终 
都 会 发 布 一 个 事件 ， 当 然 这 样 的 前 提 是 fast 至 少 已 经 发 布 过 一 个 事件 了 。 与 之 相反 ， 
fast 流 只 是 一 个 辅助 者 ， 只 有 slow 发 布 事 件 时 才 会 用 到 它 。 函 数 作为 第 二 个 参数 传递 给 
withLatestFrom()， 它 会 将 stow 流 中 的 每 个 新 值 同 fast 流 中 的 最 新 值 结合 在 一 起 。 但 是 ， 
fast 流 中 的 新 值 并 不 会 传递 至 下 游 中 。 新 的 slow 出 现时 ， 它 们 只 会 在 内 部 更 新 。 上 述 代 
码 片段 的 输出 显示 所 有 的 stow 事件 只 会 出 现 一 次 ， 而 有 些 fast 事件 则 会 被 丢弃 。 
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在 第 一 个 fast 事件 出 现 之 前 的 所 有 stow 事件 都 会 被 悄悄 丢弃 ， 因 为 没有 与 它们 联合 的 事 
件 。 按 照 设计 ， 它 就 是 这 样 运行 的 。 如 果 你 真 的 想 要 保留 主导 流 中 的 所 有 事件 ， 那 么 必须 
要 确保 其 他 的 流 要 尽快 发 布 一 些 虚 拟 的 事件 。 例 如 ， 你 可 以 让 流 预 先 发 布 一 些 虚 拟 的 事 
件 。 下 面 的 样 例 人 为 地 延缓 了 fast 流 ， 使 它 的 所 有 事件 延迟 了 100 毫秒 (参见 3.1.3 市 )。 
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如 果 没 有 虚拟 事件 ， 则 将 会 丢失 好 几 个 stow 中 的 事件 。 但 是 使 用 startwith() 操作 符 ， 就 
可 以 创建 一 个 衍生 自 fast 的 新 0bservable。 它 马上 就 会 有 一 个 FX 值 ， 然 后 是 原始 fast 流 
中 的 值 。 


Observable<String> fast = interval(10, MILLISECONDS) 

.map(x -> "F" + x) 

.delay(100, MILLISECONDS) 

.Startwith("FX"); 
Observable<String> slow = interval(17, MILLISECONDS).map(x -> "S" + XxX); 
slow 











.withLatestFrom(fast, (s, f) -> s+":" + f) 

.forEach(System.out: :println); 
输出 显示 这 里 没有 丢弃 任何 sLow 事件 。 但 是 ， 在 开始 的 时 候 ， 多 次 看 到 了 虚拟 的 FX 事 
直到 100 上 毫秒 之 后 第 一 个 Fe 出 现 。 





hl 
个 
这 





总 的 来 说 ，startwith() 会 返回 一 个 新 的 0bservable， 它 在 订阅 的 时 候 ， 马 上 就 会 发 布 一 
些 常量 值 (如 "FX")， 然 后 才 是 原始 的 0bservable。 例 如 ， 下 面 的 代码 片段 会 依次 生成 6、 
1 和 2。 








Observable 
.just(1, 2) 
.Startwith(0) 
.Subscribe(System.out::println); 


请 参见 3.4 市 ， 了 解 与 之 类 似 的 concat() 操作 符 的 样 例 。 


2. amb( ) 操 作 符 

最 后 一 个 有 用 的 操作 符 是 amb() (以 及 ambwith())， 它 会 订阅 上 游 其 所 操控 的 所 有 
0bservable 并 等 待 第 一 个 事件 的 发 布 。 其 中 有 一 个 Observable 发 布 第 一 个 事件 之 后 ， 
anb() 会 丢弃 所 有 其 他 的 流 ， 接 下 来 只 跟踪 第 一 个 发 布 事件 的 Observable， 如 图 3-8 的 弹 
珠 图 所 示 。 
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下 面 的 样 例 曾 述 了 针对 两 个 流 时 ，amb() 是 如 何 运 行 的 。 请 注意 initialDpelay 参数 ， 它 决 
定 了 哪个 Observable 会 首先 发 布 事件 。 


Observable<String> stream(int initialDelay, int interval, String name) { 
return Observable 

.interval(initialDelay, interval, MILLISECONDS) 

.map(x -> name + X) 

.do0nSubscribe(() -> 
log.info("Subscribe to 

.do0nUnsubscribe(() -> 
log.info("Unsubscribe from " + name)); 





+ Name)) 


} 
Lf 


Observable.amb( 
stream(100, 17, "S"), 
stream(200, 10, "F") 
).subscribe(log::info); 


你 可 以 使 用 非 静态 的 ambwith() 编写 相同 功能 程序 的 代码 ， 但 是 它 的 易 读 性 稍 差 一 些 ， 因 
为 这 样 会 隐藏 掉 amb() 的 对 称 性 。 下 面 的 代码 看 起 来 像 是 基于 第 一 个 流 使 用 第 二 个 流 ， 但 
实际 上 它们 两 者 是 被 平等 对 待 的 。 

stream(100, 17, "S") 


.ambWith(stream(200, 10, "F")) 
.Subscribe(log::info); 


不 管 你 更 喜欢 哪个 版 本 ， 它 们 都 会 生成 相同 的 结果 。slow 流产 生 事 件 的 频率 更 低 ， 它 的 第 
一 个 事件 会 在 大 约 100 毫秒 之 后 出 现 ， 而 fast 流产 生 的 第 一 个 事件 则 会 在 200 毫秒 之 后 出 
现 。amb() 做 的 事情 就 是 先 订 阅 这 两 个 bbservabLe， 它 遇 到 stLow 流 中 的 第 一 个 事件 之 后 ， 
会 立即 取消 对 较 快 的 流 订 阅 ， 仅 转发 较 慢 流 中 的 事件 。 

14:46:13.334: Subscribe to S 

14:46:13.341: Subscribe to F 
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14:46:13.439: Unsubscribe from F 
14:46:13.442: 9S0 
14:46:13.456: S1 
14:46:13.473: 9S2 
14:46:13.490: S3 
14:46:13.507: S4 
14:46:13.525: S5 


在 进行 调试 的 时 候 ，doonsubscribe() 和 doOnUnsubscribe() 是 非常 有 用 的 (参见 7.4.1 
节 )。 在 订阅 了 ss 大约 100 上 毫秒 之 后 ， 请 注意 anb() 是 如 何 取消 订阅 fF 的， 这 恰好 是 5 
0bservable 发 布 第 一 个 事件 的 时 间 。 此 时 ， 监 听 来 自 F 的 事件 就 没有 任何 意义 了 。 


3.3 ”高 级 操作 符 : collect()、reduce()、scan()、 


distinct() 和 groupBy() 


有 些 操作 符 能 够 进行 更 高 级 的 转换 操作 ， 比 如 扫描 整个 序列 并 在 这 个 过 程 中 聚合 一 些 值 ， 
如 计算 平均 值 。 有 些 操作 符 甚至 是 有 状态 的 ， 它 们 在 序列 往 前 推进 的 过 程 中 管理 内 部 的 状 
态 。 这 也 是 distinct 的 运行 方式 一 一 缓存 并 丢弃 访问 过 的 值 。 


3.3.1 使 用 Scan 和 Reduce 扫 描 整 个 序列 


目前 为 止 介绍 的 所 有 操作 符 都 是 基于 单个 事件 (如 过 滤 、 映 射 或 压缩 ) 的 。 但 有 时 
候 你 希望 聚合 事件 ， 从 而 对 原始 的 流 进行 缩减 或 简化 。 以 一 个 监控 数据 传输 进度 的 
0bservable<Long> 为 例 ， 每 次 数据 发 送 成 功 ， 都 会 出 现 一 个 Long 值 ， 它 代表 了 数据 块 的 大 
小 。 这 个 信息 有 一 定 的 用 处 ,但 是 真正 值得 关心 的 是 总 计 传 输 了 多 少 字 市 。 一 个 非常 精 糕 
的 主意 就 是 使 用 全 局 变量 ， 并 在 操作 符 内 部 对 该 变量 进行 修改 。 


import java.util.concurrent.atomic.LongAdder; 

































































// 有 问题 ! 


Observable<Long> progress = transferrFile(); 


LongAdder total = new LongAdder(); 
progress.subscribe(total::add); 


就 像 其 他 的 共享 状态 一 样 ， 上 述 代码 可 能 会 导致 令 人 非常 恼火 的 并 发 缺陷 。 操 作 符 中 的 
lambda 表达 式 可 能 会 在 任意 的 线程 中 执行 ， 所 以 全 局 状态 必须 是 线程 安全 的 。 另 外 ， 还 必 
须要 将 延迟 执行 考虑 进来 。RxJava 通过 可 组 合 的 操作 符 ， 可 以 尽量 减少 全 局 变量 和 可 变 
性 ， 但 即便 有 Rx 的 保证 ， 修 改 全 局 状态 也 是 很 容易 出 错 的 。 除 此 之 外 ， 也 不 能 再 使 用 Rx 
操作 符 进 一 步 地 组 合 total 值 (比如 阶段 性 地 更 新 用 户 界面 )， 传 输 完成 时 进行 通知 也 会 更 
加 复杂 。 我 们 真正 想 要 实现 的 是 : 新 的 数据 块 出 现时 ， 增 量 累积 数据 块 的 大 小 并 报告 当前 
总 值 。 假 设 的 流 应 该 如 下 所 示 。 

Observable<Long> progress = //[10, 14, 12, 13, 14, 16] 

Observable<Long> totalProgress = /* [10, 24, 36, 49, 63, 79] 
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10 
10+14=24 
24+12=36 
36+13=49 
49+14=63 
63+16=79 
Wh 
第 一 个 条 目 会 原样 (as-is，10) 传递 至 下 游 。 但 是 ， 在 第 二 个 条 目 (14) 传递 到 下 游 之 
前 ， 它 需要 与 上 一 个 已 发 布 的 条 目 (10) 相 加 ， 也 就 是 要 发 布 24 (前 两 个 条 目的 和 )。 第 
三 个 条 目 (12) 同样 也 会 添加 到 结果 流 的 上 一 个 条 目 (24) 上 ， 也 就 是 要 发 布 36。 这 个 迭 
代 式 的 过 程 会 一 直 持 续 ， 直 到 上 游 的 0bservable 完成 。 此 时 ， 最 后 发 布 的 条 目 就 是 所 有 上 
游 事件 的 总 和 。 可 以 使 用 scan() 操作 符 实现 这 个 相对 比较 复杂 的 工作 流 。 
Observable<Long> totalProgress = progress 
.scan((total, chunk) -> total + chunk); 


scan() 会 接收 两 个 参数 : 上 一 次 生成 的 值 (也 被 称 为 累加 器 ) 以 及 上 游 0bservablte 的 当前 
值 。 在 第 一 轮 运 代 中 ，totat 就 是 来 自 progress 的 第 一 个 条 目 ， 而 在 第 二 次 运 代 中 ， 它 变 
成 了 上 一 次 scan() 操作 的 结果 值 。 如 表 3-1 所 示 。 


表 3-1: 一 行 代 表 了 一 次 scan() 循 环 





















































progress total chunk totalProgress 
10 

14 10 14 24 

12 24 12 36 

13 36 13 49 

14 49 14 63 

16 63 16 79 


scan() 就 像 一 个 推土机 ， 它 会 遍历 源 (上 游 ) 0bservable 并 对 所 有 条 目 进行 累积 。 重 载 版 本 
的 scan() 可 以 提供 一 个 初始 值 (如果 初 始 值 与 第 一 个 元 素 的 值 不 同 ， 可 以 采用 这 种 方式 )。 
Observable<BigInteger> factorials = Observable 
.range(2，100) 
.scan(BigInteger .ONE, (big, cur) -> 
big.multiply(BigInteger .valueOf(cur))); 





























factorials 将 会 生成 1、2、6、24、120、720， 等 等 。 注 意 ， 上 游 的 Observable 是 从 2 开 
始 的 ， 下 游 却 是 从 1 开始 的 ， 这 是 因为 设置 了 初始 值 (BigInteger .ONE) 。 根 据 经 验 ， 最 后 
的 Observable 应 该 总 与 累加 器 的 类 型 相同 。 所 以 ， 如 果 你 没有 为 累积 器 提供 自 定义 的 初 
始 值 ， 那 么 scan() 返回 的 T 类 型 应 该 不 会 发 生变 化 的 。 否 则 (比如 在 factorial 样 例 中 )， 
结果 就 会 是 0bservable<BigInteger> 类 型 的 ， 因 为 BigInteger 是 初始 值 的 类 型 。 显 然 ， 在 
整个 扫描 过 程 中 ， 这 个 类 型 是 不 能 变化 的 。 


有 时 候 我 们 并 不 关心 中 间 结 果 ， 只 关心 最 终结 果 。 例 如 ， 想 要 计算 传输 的 总 计 字 节 数 ， 而 
不 是 中 间 的 进度 ， 或 者 想 要 累积 某 个 可 变数 据 结构 (如 ArrayList) 中 的 所 有 值 ， 每 次 都 





























大 
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会 添加 一 个 条 目 。reduce() 就 是 专门 为 此 设计 的 。 一 个 显而易见 的 警告 : 如 果 你 的 序列 是 
无 穷 的 ，scan() 会 持续 为 每 个 上 游 的 事件 发 布 事件 ， 但 是 reduce() 将 不 会 发 布 任何 的 事 
件 。 假 设 有 一 个 由 CashTransfer 对 象 组 成 的 产 ， 它 有 一 个 返回 BigDecimal 的 getAmount() 
方法 。 想 要 计算 累积 的 转账 的 总 额 ， 如 下 的 两 种 转换 方式 是 等 价 的 ， 它 们 都 会 从 零 (ZER0O) 
开始 遍历 所 有 的 转账 记录 并 累积 总 额 。 


Observable<CashTransfer> transfers = //...; 





Observable<BigDecimal> total1 = transfers 
.reduce(BigDecimal .ZERO, 
(totalSoFar, transfer) -> 
totalSoFar .add(transfer .getAmount())); 
Observable<BigDecimal> total2 = transfers 
.map(CashTransfer: :getAmount) 
.reduce(BigDecimal .ZERO, BigDecimal::add); 


两 种 转换 会 生成 相同 的 结果 ， 第 二 种 方式 尽管 有 两 个 步骤 看 起 来 却 更 简洁 。 这 也 是 为 何 
推荐 使 用 更 小 、 更 具 组 合 性 的 转换 ， 而 不 是 采用 单个 大 型 的 转换 。 你 可 能 也 看 出 来 了 ， 
reduce() 基本 上 只 接收 最 后 一 个 元 素 的 scan()。 可 以 按照 如 下 的 方式 实现 。 
public <R> Observable<R> reduce( 
R initialValue, 
Func2<R, T, R> accumulator) { 


return scan(initialValue, accumulator).takeLast(1); 


} 


如 上 所 示 ，reduce() 其 实 就 是 扫描 整个 0bservable， 但 是 丢弃 了 除 最 后 一 个 元 素 之 外 的 其 
他 所 有 元 素 (参见 3.4 市 )。 


3.3.2 ”使 用 可 变 的 累加 器 进行 缩减 : collect() 


现在 ， 让 我 们 将 类 型 为 7T 的 有 限 事件 流转 换 为 另 一 个 流 ， 这 个 被 转换 而 成 的 流 只 有 一 个 
List<T> 类 型 的 事件 。 当 然 ， 这 个 事件 只 有 上 游 0bservable<T> 完成 的 时 候 才 会 被 发 布 出 来 。 
Observable<List<Integer>> all = Observable 
.range(10, 20) 
.reduce(new ArrayList<>(), (list, item) -> { 
list.add(item); 
return list; 


D3 


reduce() 的 这 个 样 例会 从 一 个 空 的 ArrayList<Integer> (累加 器 ) 开始 ， 并 且 会 将 发 布 
的 每 个 条 目 添加 到 该 ArrayList 中 。 负 责 进 行 缩减 (累加 ) 的 lambda 表达 式 必 须 返 回 
一 个 新 版 本 的 累加 器 。 令 人 遗憾 的 是 ，List.add() 并 不 会 返 List， 相 反 ， 它 返回 的 是 一 
个 boolean 值 。 因 此 ， 这 里 需要 一 个 显 式 的 return 语句 。 为 了 避免 这 种 元 余 ， 可 以 使 用 
collect() 操作 符 。 它 的 原理 与 reduce() 几乎 相同 ， 只 不 过 假设 针对 每 个 事件 会 使 用 相同 
的 可 变 累 加 器 ， 而 不 是 每 次 都 返回 一 个 不 可 变 的 新 累加 器 (将 其 与 不 可 变 的 BigInteger 样 
例 进 行 一 下 对 比 )， 如 下 所 示 。 
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Observable<List<Integer>> all = Observable 
.range(10, 20) 
.collect(ArrayList::new, List::add); 


collect() 另外 一 个 非常 有 用 的 用 例 就 是 将 所 有 的 事件 累积 到 一 个 StringBuilder 中 。 在 这 
种 情况 下 ， 累 加 器 是 一 个 空 的 StringBuilder ， 操 作 就 是 将 一 个 条 目 附 加 到 该 生成 器 。 
Observable<String> str = Observable 
.range(1, 10) 
.COLLect( 
StringBuilder: :new， 
(sb, x) -> sb.append(x).append(", ")) 
.map(StringBuilder::toString); 
与 其 他 的 Observable 操作 符 类 似 ，reduce() 和 collect() 都 是 非 阻塞 的 。 所 以 只 有 上 游 完 
成 的 时 候 ， 才 会 发 布 最 后 的 List<Integer>， 它 包含 0Observable.range(10，20) 发 布 的 所 有 
数字 ， 异 和 常 则 会 正常 传递 。 将 0bservable<T> 转换 为 Observable<List<T>> 非常 常见 ， 所 以 
RxJava 提供 了 内 置 的 toList() 操作 符 。 参 见 4.2 节 中 的 现实 世界 用 例 。 


3.3.3 ”使 用 singtLe() 断 言 的 obbservabLe 只 有 一 个 条 目 


有 些 0bservable 按照 定义 能 且 仅 能 发 布 一 个 值 。 例 如 ， 上 述 的 代码 片段 始终 都 只 发 布 一 个 
List<Integer>， 即 便 这 个 列表 有 可 能 是 空 的 。 在 这 种 情况 下 ， 使 用 single() 操作 符 就 是 很 
有 价值 的 了 。 它 不 会 以 任何 形式 改变 上 游 的 Observable， 然 而 ， 它 确保 该 Observable 能 日 仅 
能 发 布 一 个 事件 。 如 果 这 种 假设 是 错误 的 ， 将 会 收 到 一 个 异常 ， 而 不 是 难以 预料 的 结果 。 






































3.3.4 ”使 用 distinct() 和 distinctuntilChanged() 丢 弃 重 复 


条 目 
简单 随机 值 组 成 的 无 穷 流 是 非常 有 用 的 ， 特 别 是 在 与 其 他 流 组 合 的 时 候 。 如 下 的 
Observable 会 生成 0 到 1000 之 间 的 伪 随 机 Integer 值 。 
Observable<Integer> randomInts = Observable.create(subscriber -> { 
Random random = new Random(); 


while (!subscriber.isUnsubscribed()) { 
subscriber .onNext(random.nextInt(1000)); 











} 
]); 
显然 ， 这 里 可 能 会 出 现 重复 的 值 ，take(1601) 中 肯定 至 少 有 一 个 重复 的 值 。 但是， 如 果 我 
们 想 客 视 一 个 更 少 的 〈 比 如 10 个 )、 唯 一 的 随机 值 ， 又 该 怎么 办 呢 ? 内 置 的 distinct() 操作 
符 会 自动 丢弃 上 游 0bservable 中 出 现 过 的 事件 ， 确 保 只 有 唯一 的 事件 才 会 被 传递 到 下 游 。 
Observable<Integer> uniqueRandomInts = randomInts 


.distinct() 
.take(10); 









































注 6: 仅 有 1000 个 可 能 唯一 的 nextInt(1000) 结果 。 
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每 次 有 新 的 值 从 上 游 Observable(randomInts) 发 布 出 来 ，distinct() 操作 符 内 部 就 会 确保 
这 个 值 没 有 出 现 过 。 这 种 比较 是 通过 equals() 和 hashCcode() 来 完成 的 ， 所 以 要 确保 这 两 
种 方法 是 按照 Java 指南 实现 的 (两 个 相等 的 对 象 必须 要 具有 相同 的 hash code)。 有 意思 的 
是 ，take(1901) 最 终 会 以 随机 顺序 发 布 0 到 999 之 间 的 所 有 单个 值 ， 但 是 永远 不 会 完成 ， 
因为 在 0 到 999 之 间 没 有 第 1001 个 int 类 型 的 唯一 值 。 
2.5 节 介 绍 过 0bservable<twitter4j.Status>， 它 会 发 布 社交 媒体 网 站 Twitter 的 状态 更 新 。 
每 次 用 户 一 发 布 状态 更 新 ， 这 个 0bservable 就 会 推送 新 的 事件 。Status 对 象 包含 了 多 个 
属性 ， 比 如 getText()、getUser() 等 。 鉴 于 重复 几乎 不 可 能 出 现 ， 所 以 distinct() 操作 
符 对 于 Status 事件 并 没有 太 大 的 意义 。 但 是 ， 如 果 只 想 查 看 每 个 用 户 第 一 次 更 新 的 文本 
(status.getUser().getId() 会 返回 Long 类 型 的 值 ) ， 该 怎样 实现 呢 ? 显然 ， 可 以 抽取 这 个 
唯一 的 属性 并 基于 它 运 行 distinct()。 


Observable<Status> tweets = //... 





















































Observable<Long> distinctUserIds = tweets 
.map(status -> status.getUser().getId()) 
.distinct(); 


遗憾 的 是 ， 在 执行 distinct() 的 时 候 ， 原 始 的 Status 对 象 丢失 了 。 真 正 想 要 的 是 这 种 方 
式 : 抽取 事件 的 属性 ， 从 而 决定 唯一 性 。 如 果 抽 取出 来 的 属性 (也 就 是 所 谓 的 key) 之 前 
出 现 过 ， 那 么 两 个 事件 就 被 认为 是 相等 的 (后 者 会 被 丢弃 )， 如 下 所 示 。 
Observable<Status> distinctUserIds = tweets 
.distinct(status -> status.getUser().getId()); 


key 返回 的 值 会 使 用 equals() 和 hashcode() 与 已 有 的 key 进行 对 比 。 需 要 注意 的 一 点 是 ， 
distinct() 必须 要 记 住 到 目前 为 止 出 现 的 所 有 事件 /key (参见 3.6 节 ， 想 要 针对 唯一 的 事 
件 仅 处 理 一 次 的 时 候 ，distinct() 是 非常 有 用 的 ) 。 

在 实践 中 ，distinctUntitLChanged() 通常 更 有 用 。 在 使 用 distinctUntiLChanged() 的 时 候 ， 
如 果 给 定 的 事件 与 上 一 个 事件 相同 ， 就 会 被 丢弃 (默认 会 使 用 equals() 进行 对 比 )。 如 
果 能 够 接收 到 某 个 测量 数据 的 稳定 流 ， 并 且 想 要 在 测量 值 发 生变 化 的 时 候 得 到 通知 ， 那 
么 distinctuntilChanged() 是 最 适合 的 。3.2.2 节 用 到 了 0bservable<Weather>， 其 中 的 
Weather 有 两 个 属性 : Temperature 和 Wind。 新 的 Weather 可 能 每 分 钟 就 出 现 一 次 ， 但 是 天 
气 的 变化 却 没 有 那么 频繁 。 所 以 重复 的 事件 会 被 丢弃 ， 我 们 只 关注 变更 ， 如 下 所 示 。 


Observable<Weather> measurements = //... 




























































































Observable<Weather> tempChanges = measurements 
.distinctUntilChanged(Weather::getTemperature); 


上 述 的 代码 片段 只 有 在 温度 发 生变 化 (wind 的 变化 不 考虑 在 内 ) 的 时 候 ， 才 会 发 布 
Weather 事件 。 显 然 ， 如 果 想 要 在 Temperature 或 Mnd 发 生变 化 的 时 候 发 布 事件 ， 那 么 
无 参 的 distinctUntiLChanged() 就 能 很 好 地 实现 该 功能 ， 当 然 这 里 假设 Weather 实现 了 
equals() 方法 。distinct() 和 distinctuntilChanged() 的 重要 区 别 在 于 后 者 可 以 产生 重复 
的 事件 ， 但 前 提 是 重复 的 值 被 另 一 个 不 同 值 隔 开 。 例 如 ， 每 天 都 可 能 会 出 现 相 同 的 温度 ， 
但 是 它们 会 被 更 冷 或 更 热 的 温度 隔 开 。 另 外 ，distinctUntiLChanged() 必须 要 记 住 上 一 个 
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出 现 的 值 。 与 之 相对 的 是 distinct()， 它 必须 从 流 的 起 始 就 跟踪 所 有 唯一 的 值 。 这 意味 














着 ， 相 对 于 distinct()，distinctuntilchanged() 的 内 存 消 耗 是 可 预测 的 固定 值 。 
3.4 使 用 skip()、takewhite() 等 进行 切片 和 切 块 


从 来 都 没有 必要 阅读 整个 流 ， 在 处 理 hot 类 型 的 无 穷 流 时 更 应 如 此 ， 当 然 这 一 特性 并 不 局 限 
于 这 种 类 型 的 流 。 实 际 上 ， 对 0bservable 进行 切片 ， 并 且 只 使 用 其 中 很 小 的 一 个 子 集 是 非 
常常 见 的 。 本 市 中 的 大 多 数 操作 符 都 有 样 例 ， 除 非 它 们 本 身 符合 最 小 惊讶 原则 。 而 像 take() 
或 last() 这 样 操作 符 是 非常 有 用 的 ， 不 能 省 略 。 如 下 是 这 些 操作 符 的 一 个 非 详尽 列表 。 


口 











take(n) 和 skip(n) 
take(n) n 个 事件 之 后 提前 截断 源 0bservable， 随 后 取消 订阅 
(如 果 上 游 的 条 目 达 不 到 n 个 ， 那 么 就 会 提前 完成 了 )。skip(n) 则 恰好 相反 ， 它 会 丢弃 
前 n 个 元 素 ， 然 后 把 上 游 pl 的 第 n+1 个 事件 作为 起 点 ， 开 始 发 布 事件 。 这 两 
个 操作 符 都 具有 一 定 的 容错 性 ， 负数 会 被 视 为 零 ， 超 出 0bservable 的 大 小 也 不 会 被 视 
为 缺陷 。 

Observable.range(1, 5).take(3); //[1, 2, 3] 


Observable.range(1, 5).skip(3); //[4, 5] 
Observable.range(1, 5).skip(5); //[] 














ee 和 skipLast(n) 

是 另外 A 性 的 操作 符 。takeLast(n) 只 会 发 布 流 在 完成 之 前 的 最 后 n 
个 们 ， 在 内 部 ， 这 个 操作 符 必须 要 有 一 个 缓冲 区 ,保存 最 后 的 n 个 值 ， 接 收 到 完成 通 
知 后 ， ne 在 无 穷 流 上 调用 ey ge 
因为 它 不 会 发 布 任何 的 内 容 一 一 流 永远 不 会 终止 ， 所 以 也 就 不 会 有 最 后 的 事件 。 
skipLast(n) 则 会 发 布 上 游 Observable 中 除了 最 后 n 个 事件 之 外 的 其 他 所 有 事件 。 
部 ，skipLast() 接收 到 n+1 个 事件 的 时 候 ， 就 可 以 发 布 第 一 个 值 ， 在 接收 到 第 n+2 个 事 
件 时 ， 就 可 以 发 布 第 二 个 值 ， 以 此 类 推 。 


Observable.range(1, 5).takeLast(2); //[4，5] 
Observable.range(1, 5).skipLast(2); //[1, 2, 3] 


























first() 和 last() 

无 参 的 first() 和 last() 操作 符 可 以 分 别 通过 take(1).singLe() 和 takeLast(1). 
single() 来 实现 ， 这 种 方式 很 好 地 描述 了 两 个 操作 符 的 行为 。 额 外 的 single() 操作 符 
会 确保 下 游 的 Observable 只 会 发 布 一 个 值 或 者 异常 。 另 外 ，first() 和 Last() 都 有 接 
收 断 言 的 重 载 版 本 来 实现 。 如 果 有 断言 ， 它 们 返回 的 就 不 一 定 真 的 是 第 一 个 /最 后 一 个 
值 ， 而 是 满足 给 定 条 件 的 第 一 个 /最 后 一 个 值 。 


takeFirst(predicate) 

takeFirst(predicate) 操作 符 可 以 表述 为 filter(predicate).take(1)。 这 个 操作 符 与 first 
(predicate) 的 唯一 区 别 在 于 如 果 没 有 匹配 的 值 ， 它 不 会 抛 出 NoSuchELementException。 
takeUntil(predicate) 和 takeWhile(predicate) 

takeUntil(predicate) 和 takeWhile(predicate) 的 关联 性 很 强 。takeUnti1l() 会 发 布 上 






































游 observable 中 的 值 ， 但 是 在 发 布 完 第 一 个 匹配 predicate 的 值 之 后 ， 它 就 会 完成 并 
取消 订阅 。takeWhile(predicate) 则 与 乙 相 反 ， 只 要 这 些 值 与 给 定 的 断言 匹配 ， 它 会 一 
直 发 布 值 。 所 以 ， 区 别 在 于 takeUntil() 会 发 布 第 一 个 不 匹配 的 值 ， 而 takenhite() 则 
` 会 。 这 些 操 作 符 非常 重要 ， 它 们 基于 发 布 的 事件 ， 有 条 件 地 对 0bservable 取消 订阅 。 
否则 ， 操 作 符 就 需要 以 某 种 方式 与 Subscription 实例 进行 交互 了 (参见 2.3 市 )， 操 作 
符 在 调用 的 时 候 ， 这 个 实例 其 实 是 无 法 得 到 的 。 

Observable.range(1, 5).takeUntil(x -> x == 3); //[1，2，3] 

Observable.range(1, 5).takeWhile(x -> x != 3); //[1, 2] 
































elementAt(n) 

根据 索引 抽取 特定 条 目的 需求 并 不 和 常见， 针对 这 种 情况 可 以 使 用 内 置 的 elementAt(n) 
操作 符 。 它 非常 严格 ， 如 果 上 游 0bservablte 的 长 度 不 够 或 者 索引 为 负 时 ， 它 会 产生 
Index0ut0fBoundsException。 当 然 ， 它 返回 的 是 与 上 游 类 型 T 相同 的 0bservabLe<T>。 








...0rDefault() 操作 符 

这 一 节 中 的 很 多 操作 符 都 很 严格 ， 可 能 会 导致 异常 的 抛 出 ， 比 如 上 游 0bservablte 为 空 
时 ， 执 行 first() 操作 就 会 抛 出 异常 。 在 这 种 情况 下 ， 有 很 多 的 .….0rDefault() 操作 
符 能 够 将 异常 替换 为 一 个 默认 值 。 这 些 操作 符 的 作用 不 言 自明 : elementAtOorDefault()、 
firstorDefault()、1lastOrDefault() 以 及 singleOrDefault()。 





count() 
count() 是 一 个 非常 有 趣 的 操作 符 ， 它 会 计算 上 游 observable 发 布 了 多 少 个 事件 。 顺 便 
提 一 下 ， 如 果 你 需要 知道 上 游 发 布 的 条 目 中 有 多 少 满足 给 定 的 断言 ， 那 么 按照 习惯 用 
法 ，filter(predicate).count() 能 够 实现 该 功能 。 所 有 的 操作 符 都 是 延迟 执行 的 ， 所 
以 对 于 非常 大 型 的 流 ， 这 种 方式 依然 可 行 。 显 然 ， 对 于 无 穷 流 来 说 ，count() 并 不 会 发 
布 任何 的 值 。 你 可 以 使 用 reduce() 很 容易 地 实现 count()， 如 下 所 示 。 
Observable<Integer> size = Observable 

.just('A', 'B', 'C', 'D') 

.reduce(0, (sizeSoFar, ch) -> sizeSoFar + 1); 




















all(predicate)、 exists(predicate) 和 contains(value) 

有 时 候 ， 确 保 给 定 0bservablte 的 所 有 事件 均 匹 配 某 个 断言 是 非常 有 用 的 。 如 果 上 游 的 
Observable 正常 完成 ， 并 且 所 有 的 值 均 匹配 断言 ， 那 么 all(predicate) 会 发 布 true。 
一 旦 发 现 第 一 个 不 符合 断言 的 值 ， 它 就 会 发 布 false。exists(predicate) 与 aLL() 完全 
相反 ， 发 现 第 一 个 匹配 断言 的 值 之 后 ， 它 就 会 发 布 true; 但 是 如 果 上 游 的 Observable 
正常 完成 ， 并 且 没 有 发 现任 何 匹配 的 值 ， 那 么 它 就 会 发 布 false。 通 常 ， 在 exists() 中 
的 断言 会 与 某 些 常量 进行 对 比 ， 在 这 种 情况 下 ， 你 还 可 以 使 用 contains() 操作 符 。 


Observable<Integer> numbers = Observable.range(1, 5); 















































numbers.all(x -> x != 4); //[falsel] 
Numbers.exists(x -> x == 4); //[true] 
numbers.contains(4); //[true] 
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3.4.1 组 合流 的 方式 : concat()、merge() 和 switchOnNext() 


concat() (以 及 实例 方法 concatwith()) 能 够 将 两 个 0bservable 连接 在 一 起 : 第 一 个 
Observable 完成 的 时 候 ，concat() 会 订阅 第 二 个 。 非 常 重要 的 一 点 ， 当 且 仅 当 第 一 个 
Observable 完成 的 时 候 ，concat() 才 会 订阅 第 二 个 Observable (参见 3.1.5 节 )。concat() 
甚至 能 够 将 不 同 的 操作 符 用 到 同一 个 上 游 0bservable 上 。 例 如 ， 如 果 你 只 想 接收 一 个 非常 
长 的 流 的 前 几 个 和 最 后 几 个 条 目 ， 那 么 可 以 通过 如 下 的 方式 实现 。 

Observable<Data> veryLong = //... 

final Observable<Data> ends = Observable.concat( 


veryLong.take(5), 
veryLong.takeLast(5) 




















); 
需要 注意 ， 上 面 的 代码 订阅 了 veryLong 两 次 ， 这 可 能 并 非 想 要 的 效果 。concat() 的 另外 一 
个 样 例 就 是 在 第 一 个 流 不 发 布 任何 内 容 条 目的 情况 下 ， 提 供 备用 (fallback) 值 。 


Observable<Car> fromCache = loadFromCache(); 
Observable<Car> fromDb = loadFromDb(); 


























Observable<Car> found = Observable 
.concat(fromCache, fromDb) 
.first(); 


Observable 是 延迟 执行 的 ， 所 以 LoadFromCache() 和 ToadFromDb() 实际 上 都 还 没有 加 载 数 
据 。 如 果 缓 存 为 空 ，LoadFromCache() 可 能 不 发 布 任何 值 就 完成 了 ， 但 是 LoadFromDb() 始 
终 都 能 返回 一 个 Car。concat() 之 后 的 first() 会 首先 订阅 fromCache， 如 果 它 能 发 布 一 
个 条 目 出 来 ， 样 例 将 不 再 订阅 frompb。 但 是 ， 如 果 fromCache 为 空 ，concat() 会 继续 订阅 
fromDb 并 从 数据 库 中 加 载 数据 。 


实际 上 ，concat() 操作 符 与 merge() 和 switchMap() 的 关系 非常 密切 。concat() 的 运行 方 
式 类 似 于 普通 List<T> 的 连接 : 首先 ， 它 从 第 一 个 流 中 提取 所 有 的 条 目 ， 并 且 仅 在 第 一 个 
流 完成 的 情况 下 ， 才 会 开始 消费 第 二 个 流 中 的 条 目 。 当 然 ， 与 之 前 看 到 的 所 有 操作 符 一 
样 ，concat() 是 非 阻 寒 的 ， 只 有 底层 的 流 发 布 事件 的 时 候 ， 它 才 会 随 之 发 布 事件 。 现 在 ， 
对 比 一 下 concat() 和 merge() (参见 3.2.1 节 )， 以 及 马上 要 介绍 的 switchOnNext()。 


假设 有 一 组 人 ， 每 个 人 都 有 一 个 麦克 风 。 每 个 麦克 风 都 建 模 为 0bservabte<String>， 甚 中 
每 个 事件 代表 一 个 单词 。 显 然 ， 事件 在 说 出 这 些 单词 的 时 候 才 能 出 现 。 为 了 模拟 这 种 行 
为 ， 我 们 会 创建 一 个 简单 的 0bservable 进行 演示 ， 它 本 身 是 非常 有 意思 的 。 如 下 所 示 。 


Observable<String> speak(String quote, long millisPperChar) { 
String[] tokens = quote.replaceAll("[:,]", "").split(" "); 
Observable<String> words = Observable.from(tokens); 
Observable<Long> absoluteDelay = words 

.map(String::length) 

.map(len -> Len * millisperChar) 

.scan((total, current) -> total + current); 
return words 

.ZipWith(absoluteDelay.startWith(0L), Pair::of) 

.flatMap(pair -> just(pair.getLeft()) 
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.delay(pair.getRight(), MILLISECONDS)); 
} 


上 述 的 代码 片段 非常 复杂 ， 所 以 先 逐 行 学 习 一 下 。 以 String 的 形式 接收 一 个 任意 的 文本 并 
将 其 拆 分 为 单词 ， 使 用 正则 表达 式 删除 掉 标 点 符号 。 现 在 ， 对 于 每 个 单词 ， 计 算 说 出 该 单 
词 需要 的 时 间 ， 用 单词 的 长 度 乘 以 mLLisPerChar 就 可 以 获得 。 然 后 ， 根 据 时 间 的 推移 将 
这 些 单词 传递 出 去 ， 这 样 的 话 ， 每 个 单词 都 会 按照 上 述 样 例 计 算出 来 的 延迟 依次 出 现 。 显 
然 ， 简 单 的 fron 操作 符 是 不 够 的 。 


Observable<String> words = Observable.from(tokens); 


我 们 想 让 单词 按照 一 定 的 延迟 出 现 ， 这 个 延迟 要 基于 上 一 个 单词 的 长 度 。 第 一 个 比较 原始 
的 实现 方式 就 是 直接 根据 每 个 单词 的 长 度 决定 延迟 。 
words.fLatMap(word -> Observable 


.just(word) 
.delay(word.length() * millisPperChar, MILLISECONDS)); 


这 种 方式 是 不 正确 的 。0bservable 首先 会 同时 发 布 出 所 有 单字 母 单词 。 然 后 ， 稍 等 片刻 ， 
它 会 发 布 出 所 有 含有 两 个 字母 的 单词 ， 随 后 是 三 个 字母 的 单词 。 但 是 ， 我 们 想 要 实现 的 效 
果 是 立即 发 布 第 一 个 单词 ， 然 后 基于 一 定 的 延迟 发 布 第 二 个 单词 ， 这 里 的 延迟 要 由 第 一 个 
单词 的 长 度 决 定 。 这 听 起 来 非常 复杂 ， 但 其 实 非 常 有 意思 。 首 先 ， 根 据 words 构建 一 个 辅 
助 流 ， 它 只 包含 每 个 单词 引发 的 的 相对 延迟 ， 如 下 所 示 。 

words 


.map(String::length) 
.map(Len -> Len * millisperChar); 









































假设 millisPerchar 的 值 为 100，words 的 内 容 是 Though this be madness， 首 先 得 到 了 如 
下 的 流 : 600，400，200，700。 如 果 只 是 按照 持续 时 间 来 对 每 个 单词 进行 delay() 操作 ， 
be 会 是 第 一 个 出 现 的 单词 ， 其 他 单词 的 顺序 也 会 被 打 乱 。 但 真正 想 要 的 是 绝对 延迟 的 累加 
值 ， 如 : 600，600 + 400 = 1000，1000 + 200 = 1200，1200 + 700 = 1900。 通 过 scan() 操作 
符 ， 这 非常 容易 实现 (参见 3.3.1 节 )。 
Observable<Long> absoluteDelay = words 
.map(String: :Length) 


.map(Len -> Len * millisperChar) 
.scan((total, current) -> totaL + current); 


现在 ， 有 了 一 个 单词 的 序列 和 一 个 由 每 个 单词 绝对 延迟 组 成 的 序列 ， 我 们 可 以 将 这 两 个 流 
联合 起 来 。 这 就 是 zip() 能 够 发 挥 作用 的 地 方 ， 如 下 所 示 。 
words 


.ZipWith(absoluteDelay.startWith(0L), Pair::of) 
.flatMap(pair -> just(pair.getLeft())) 


这 样 做 很 有 意义 ， 因 为 知道 这 两 个 流 具有 完全 相同 的 大 小 ， 并 且 彼 此 完全 同步 ， 或 者 可 以 
说 几乎 同步 。 我 们 不 想 让 第 一 个 单词 有 任何 的 延迟 ， 但 是 ， 第 一 个 单词 的 长 度 会 影响 第 二 
个 单词 的 延迟 ， 第 一 个 单词 和 第 二 个 单词 的 总 长 度 则 会 影响 第 三 个 单词 的 延迟 ， 以 此 类 
推 。 通 过 为 absoluteDelay 添加 一 个 初始 值 为 6 的 值 ， 能 够 很 容易 地 实现 这 一 点 。 
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import org.apache.commons.lang3.tuple.Pair; 


words 
.ZipWith(absoluteDelay.startWith(0L), Pair: 
.flatMap(pair -> just(pair.getLeft()) 
.delay(pair.getRight(), MILLISECONDS)); 


为 单词 构建 一 个 与 之 配对 的 序列 ， 也 就 是 每 个 单词 的 绝对 延迟 ， 
有 延迟 的 。 这 些 配对 的 值 如 下 所 示 。 

(Though，0) 

(this, 600) 

(be, 1000) 

(madness, 1200) 


:of) 


并 且 确 保 第 














这 是 说 话 的 时 间 线 ， 也 就 是 每 个 单词 以 及 与 之 相关 的 时 间 点 。 
对 元 素 转换 成 随时 间 不 断 出 现 的 单元 素 0bservable。 


flatMap(pair -> just(pair.getLeft()) 
.delay(pair.getRight(), MILLISECONDS)); 


在 完成 这 些 准备 工作 之 后 ， 我 们 可 以 看 一 下 concat()、 
区 别 。 假 设 有 三 个 人 正在 引述 威廉 莎士比亚 的 《哈姆雷特 》， 


Observable<String> alice = speak( 

"To be, or not to be: that is the question", 110); 
Observable<String> bob = speak( 

"Though this be madness, yet there is method in't", 
Observable<String> jane = speak( 

"There are more things in Heaven and Earth, " + 

"Horatio, than are dreamt of in your philosophy", 100); 











如 下 所 示 。 


90); 





和 一 个 自 


单词 是 没 





需要 做 的 其 余部 分 就 是 将 每 


merge() 和 switchonNext() 三 者 的 


你 可 以 看 到 ， 每 个 人 的 节奏 都 有 轻微 的 不 同 ， 这 是 miltlisPerchar 定义 的 。 如 果 所 有 人 同 
时 说 话 ， 会 怎么 样 呢 ? RxJava 能 够 回 答 这 个 问题 。 
Observable 
.merge( 
alice.map(w -> "Alice: " + W)， 
bob .map(w -> "Bob: " + WwW)， 
jane.map(w -> "Jane: " + w) 
) 
.Subscribe(System.out: :println); 

















输出 非常 混乱 ， 每 个 人 说 出 的 单词 都 交织 在 一 起 ， 我 们 听 到 的 都 是 噪声 。 如 有 果 不 是 每 个 语 








句 都 有 个 前 级 ， 


To 
Though 
There 
be 

or 

are 
not 


以 下 的 输出 内 容 会 非常 难以 理解 。 














Alice: 
Bob: 
Jane: 
Alice: 
Alice: 
Jane: 
Alice: 





Bob : this 
Jane: more 


Alice: to 
Jane: things 
Alice: be 

Bob: be 
Alice: that 
Bob: madness 
Jane: in 
ALice: is 
Jane: Heaven 
ALice: the 
Bob: yet 
Alice: question 
Jane: and 
Bob: there 
Jane: Earth 
Bob: is 


Jane: Horatio 
Bob: method 
Jane: than 


Bob: in't 
Jane: are 
Jane: dreamt 
Jane: of 
Jane: in 


Jane: your 
Jane: phiLosophy 


这 就 是 nerge() 的 运行 方式 : 它 立 即 订 阅 每 个 人 对 应 的 单词 并 将 其 转发 至 下 游 ， 而 不 管 过 
程 中 这 些 单 词 是 哪个 人 说 的 。 如 有 果 两 个 流 几 乎 同时 发 布 事件 ， 那 么 它们 都 会 立即 被 转发 至 
下 游 。 在 这 个 操作 符 中 没有 事件 的 缓冲 和 暂停 。 


如 果 将 merge() 替换 为 concat() 操作 符 ， 情 况 会 发 生 很 大 的 变化 。 


Alice: To 
Alice: be 
Alice: or 
Alice: not 
Alice: to 
Alice: be 
Alice: that 
Alice: is 
Alice: the 
Alice: question 
Bob: Though 
Bob: this 
Bob: be 

Bob: madness 
Bob: yet 
Bob: there 
Bob: is 

Bob: method 
Bob: in't 
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Jane: There 
Jane: are 
Jane: more 
Jane: things 


Jane: in 
Jane: Heaven 
Jane: and 


Jane: Earth 
Jane: Horatio 
Jane: than 


Jane: are 
Jane: dreamt 
Jane: of 
Jane: in 


Jane: your 
Jane: philosophy 


现在 ， 顺序 完全 没有 问题 了 。concat(alice，bob，jane) 首先 会 订阅 alice， 并 持续 转发 

这 个 0bservable 的 事件 ， 直 到 它 的 内 容 耗 尽 并 完成 。 然 后 ，concat() 会 切换 到 bob 上 。 请 
思考 一 下 ，hot 类 型 和 cold 类 型 的 0bservable 的 差异 。 在 使 用 merge() 的 时 候 ， 所 有 流 的 
全 部 事件 都 会 进行 转发 ， 因 为 merge() 会 立即 订阅 事件 流 。 但 是 ，concat() A 
一 个 流 ， 所 以 ， 如 果 是 hot 类 型 的 Observable， 你 可 能 会 得 到 不 同 于 预期 的 输出 。 第 
Observable 完成 的 时 候 ， 第 二 个 Observable 可 能 会 发 布 完 全 不 同 的 事件 序列 。 0 
是 ，concat() 并 不 会 缓冲 第 二 个 Observable 的 事件 ， 直 到 第 一 个 Observable 完成 ， 它 只 
是 延迟 对 第 二 个 0bservable 的 订阅 。 


switchonNext() 是 以 完全 不 同 的 方式 进行 组 合 的 操作 符 。 假 设 有 一 个 0bservable 
<0bservable<T>>， 这 个 流 中 的 每 个 事件 本 身 也 是 一 个 流 。 这 种 情况 是 非常 有 意义 的 。 例 
如 ， 如 果 你 有 一 组 移动 昨 话 冯 不 岂 志 度 兴 听 开 网络 (外 部 流 )， 每 个 新 的 连接 都 是 一 个 独 
立 的 事件 ， 但 是 每 个 这 样 的 事件 都 是 由 独立 心跳 信息 (0bservable<Ping>) 组 成 的 流 。 在 
这 样 的 场景 下 ， 会 有 一 个 0Observable<0bservable<String>>， 其 中 每 个 内 部 流 代 表 每 个 人 
( 即 aLtce、bob 或 jane) 的 引述 。 


import java.util.Random; 
































Random rnd = new Random(); 

Observable<Observable<String>> quotes = just( 
alice.map(w -> "Alice: " + w), 
bob .map(w -> "Bob: "+ WwW), 
jane.map(w -> "Jane: + W)); 


首先 ， 将 alice、bob 和 jane 的 0bservable 包装 到 一 个 0bservabLe<0bservabLe<String>> 
中 。 重 申 一 下 : quotes 0bservable 立即 发 布 三 个 事件 ， 每 个 事件 都 是 一 个 内 部 0bservable 
<String>。 每 个 内 部 的 0bservabLe<String> 代表 每 人 说 的 单词 。 为 了 阐述 switchonNext() 
是 如 何 运 行 的 ， 应 该 延迟 内 部 0bservable 的 发 布 。 以 下 代码 并 不 是 延迟 这 个 0bservable 
(变种 4) 中 的 每 个 单词 ， 而 是 延迟 整个 Observable (变种 妃 略 有 差异 )。 

//A 


map(innerObs -> 
innerObs.delay(rnd.nextInt(5), SECONDS)) 























//B 
flatMap(innerObs -> just(innerObs) 
.delay(rnd.nextInt(5), SECONDS)) 


在 变种 4 中 ，0bservable 会 立即 出 现在 外 层 流 中 ,但 是 在 一 定 延 迟 之 后 才 会 发 布 事件 。 
在 变种 8B 中 ， 我 们 及 时 转移 了 整个 Observable 所 以 它 出 现在 外 层 Observable 
中 的 时 间 要 晚 得 多 。 现 在 ， 已 经 介绍 了 为 何 需 要 这 杂 的 操作 符 。 静 态 的 concat() 
和 merge() 操作 符 都 能 操作 由 国定 列表 组 成 的 ls 或 者 由 0bservable 组 成 的 
Observable。 而 对 switchonNext() 来 说 ， 后 者 会 生效 。 


switchonNext() 首先 会 订阅 一 个 外 层 的 Observable<0bservable<T>>， 这 个 外 层 0bservable 
会 发 布 内 层 的 0bservabLe<T>。 第 一 个 内 层 0bservabtLe<T> 出 现 的 时 候 ， 这 个 操作 符 就 
会 订阅 它 并 开始 往 下 游 推送 1 类型 的 事件 下 一 个 内 层 0bservable<T> 出 现 的 话 ， 会 发 
生 什 么 呢 ? switchonNext() 将 会 取消 对 第 一 个 Observable<T> 的 订阅 ， 从 而 丢弃 第 一 个 
Observable<T>， 然 后 切换 至 下 一 个 Observable<T> (这 种 做 法 也 符合 它 的 名 称 )。 换 句 话 
说 ， 如 果 有 一 个 用 流 组 成 的 流 时 ，switchonNext() 只 会 往 下 游 转发 最 后 的 内 部 流 的 事件 ， 
即便 旧 的 流 依然 在 生成 新 的 事件 也 会 被 丢弃 。 


《哈姆雷特 》 样 例会 如 下 所 示 。 


Random rnd = new Random(); 
Observable<Observable<String>> quotes = just( 















































alice.map(w -> "Alice: " + W)， 
bob.map(w -> "Bob: " + w), 
jane.map(w -> "Jane: " + w)) 


.flatMap(innerObs -> just(innerObs) 
.delay(rnd.nextInt(5), SECONDS)); 


Observable 
.SwitchOnNext(quotes) 
.Subscribe(System.out: :println); 


因为 随机 性 ， 这 个 样 例 可 能 产生 的 输出 如 下 所 示 。 


Jane: There 


Jane: are 
Jane: more 
Alice: To 
Alice: be 
Alice: or 
Alice: not 
Alice: to 
Bob: Though 
Bob: this 
Bob: be 
Bob: madness 
Bob: yet 
Bob: there 
Bob: is 
Bob: method 
Bob: in't 
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每 个 人 在 开始 讲话 之 前 ， 都 会 有 0 秒 到 4 秒 的 任意 延迟 。 在 这 次 执行 中 ， 首 先 出 现 的 是 
Jane 的 0bservabLe<String>， 但 是 在 讲 完 几 个 单词 之 后 ，Alice 的 0bservabLe<String> 在 
外 层 0Observable 中 出 现 了 。 此 时 ，swttchonNext() 会 取消 对 jane 的 订阅 ， 然 后 我 们 就 再 
也 昕 不 到 她 的 引述 了 。 这 个 observablte 会 被 丢弃 和 和 忽略，switchonNext() 此 时 只 会 监听 
alice。 但 是 ， 因 为 Bob 的 引述 出 现 ， 这 个 内 层 0bservable 随后 也 会 被 中 断 。 


从 理论 上 讲 ， 如 果 内 层 Observable 不 出 现 重合 ， 也 就 是 在 当前 Observable 完成 之 后 ， 下 
一 个 Observable 才 出 现 ，switchonNext() 能 够 生成 内 层 0Observable 的 所 有 事件 。 


如 果 每 个 内 层 Observable 只 是 延迟 事件 (还 记得 变种 4 的 实现 吗 ? )， 而 不 是 延迟 
Observable 本 身 ， 会 怎样 呢 ? 这 样 ， 三 个 内 层 0bservable 会 同时 出 现在 外 层 0bservabte 
中 ， 而 switchOnNext() 只 会 订阅 其 中 之 一 。 


3.4.2 ”使 用 groupBy() 实 现 基于 标准 的 切 块 流 

与 领域 驱动 设计 (domain-driven design， 关 于 领域 驱动 设计 的 更 多 信息 ， 请 参阅 Vaughn 
Vernon 的 《实现 领域 驱动 设计 》)) 经 常 一 起 使 用 的 一 项 技术 叫 作 事件 渊源 (event 
Sourcing) 。 在 这 种 架构 风格 中 ， 数 据 不 会 以 当前 状态 快照 的 形式 进行 存储 ， 也 不 能 进行 修 
改 ， 也 就 是 不 能 使 用 SQL UPDATE 查询 。 相 反 ， 它 会 将 已 经 发 生 的 事情 以 不 可 变 领 域 事 
件 (fact) 的 形式 保存 在 只 能 追加 的 数据 存储 中 。 使 用 这 种 设计 永远 不 会 覆盖 任何 数据 ， 
实际 上 就 是 免费 得 到 了 一 个 审计 日 志 。 除 此 之 外 ， 查 看 实时 数据 的 唯一 方式 就 是 从 一 个 空 
视图 (empty view) 开始 ， 依 次 应 用 这 些 fact。 

在 事件 济源 中 ， 基 于 初始 的 空 状态 应 用 事件 被 称 为 投影 (projection)。 一 个 fact 源 可 
以 驱动 多 个 投影 。 例 如 ， 可 能 会 有 与 预定 系统 相关 的 fact 流 ， 比 如 TicketReserved、 
ReservationConfirmed 和 TicketBought， 这 里 的 名 称 使 用 过 去 式 是 非常 重要 的 ， 因 为 fact 
反映 的 都 是 发 生 过 的 操作 和 事件 。 从 一 个 fact 源 〈 也 是 唯一 的 事实 来 源 ) ， 可 以 衍生 多 个 
迷 影 ， 如 下 所 示 。 


。 所 有 确认 预定 的 清单 。 
。 今天 所 有 取消 预定 的 清单 
。 每 周 的 总 收入 。 

系统 演化 的 时 候 ， 可 以 丢弃 旧 的 投影 并 构建 新 的 ， 这 主要 是 因为 能 够 立即 以 fact 的 形式 收 
集 数据 。 假 设想 要 构建 一 个 包含 所 有 预定 信息 及 其 状态 的 投影 。 为 了 实现 这 一 点 ， 必 须要 
消费 所 有 的 ReservationEvents， 并 将 其 应 用 到 合适 的 预定 信息 中 。 针 对 不 同类 型 的 事件 ， 
每 个 ReservationEvent 都 有 对 应 的 子 类 ， 如 TicketBought。 同 时 ， 每 个 事件 都 有 一 个 预定 
信息 的 UuID， 用 来 判断 要 将 事件 应 用 到 哪个 预定 信息 上 。 

FactStore factStore = new CassandraFactStore(); 


Observable<ReservationEvent> facts = factStore.observe(); 
facts.subscribe(this::updateProjection); 
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注 7: 参见 《实现 领域 驱动 设计 》 附 录 A 的 “阅读 模型 投射 ”部 分 。 





大 


84 | 第 3 章 


void updateProjection(ReservationEvent event) { 
UUID uuid = event.getReservationUuid(); 
Reservation res = loadBy(uuid) 
.orElseGet(() -> new Reservation(uyuid)); 


res.consume(event); 


store(event.getUuid(), res); 


} 


private void store(UUID id, Reservation modified) { 


Te 
} 


Optional<Reservation> loadBy(UUID uuid) { 


11... 
} 


class Reservation { 


Reservation consume(ReservationEvent event) { 


// 改 变 自 身 


return this; 
} 
} 


显然 ，facts 流 是 以 Observable 的 形 

















(领域 事件 )。 系 统 的 其 他 组 成 部 分 


式 来 进行 表述 的 。 系 统 中 的 其 他 一 些 部 分 接收 API 调 





用 或 Web 请 求 ， 然 后 对 发 生 的 事情 做 出 反应 (比如 向 客户 收取 信用 卡 费 用 ) 并 存储 fact 


(其 至 其 他 的 系统 ) 可 以 通过 订阅 流 消费 这 些 fact， 然 


后 基于 任何 角度 构建 当前 系统 状态 的 快照 。 代 码 非常 简单 : 每 个 ReservationEvent 从 投影 





数据 存储 中 加 载 一 个 Reservation。 


如 果 找 不 到 Reservation， 就 意味 着 这 是 该 UUID 关联 


的 第 一 个 事件 ， 所 以 就 会 从 一 个 空 的 Reservation 开始 ， 然 后 将 ReservationEvent 传递 给 
Reservation 对 象 。Reservation 可 以 对 自身 进行 更 新 以 便于 应 对 任意 类 型 的 fact， 随 后 ， 





将 Reservation 保存 回去 。 








需要 注意 ， 投 影 是 独立 于 fact 的 ， 它 们 可 以 使 用 任意 类 型 的 存储 机 制 ， 黄 至 只 保存 在 内 存 
之 中 。 另 外 ， 你 甚至 可 以 让 多 个 投影 消费 相同 的 fact 流 ， 但 是 构建 出 不 同 的 快照 。 例 如 ， 
可 以 有 一 个 Accounting 对 象 消费 相同 的 fact 流 ， 但 是 它 只 关心 现金 的 流入 和 流出 ， 另 外 一 





个 投影 可 能 只 关心 FraudDetectedfact 








， 用 来 汇总 欺诈 相关 的 信息 。 











关于 事件 渊源 的 简短 介绍 有 助 于 你 理 











对 Reservation 投影 更 新 的 速度 落后 





E 解 groupBy() 操作 符 的 用 处 。 在 一 段 时 间 之 后 ， 样 例 
了 ， 它 无 法 与 fact 生成 的 速度 保持 同步 。 数 据 存 储 可 


以 很 容易 地 处 理 并 发 读 取 和 更 新 ， 所 以 可 以 尝试 并 行 处 理 fact， 如 下 所 示 。 


Observable<ReservationEvent> facts = factStore.observe(); 








facts 





.flatMap(this: :updatepProjectionAsync) 


.Subscribe(); 


pd 


Observable<ReservationEvent> updatepProjectionAsync(ReservationEvent event) { 
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// 可 能 是 异步 的 


这 个 样 例 以 并 行 的 方式 消费 facts， 或 者 更 精确 地 说 : 接收 是 序列 化 的 ， 但 是 处 理 (在 
updateProjectionAsync() 中 ) 可 能 是 异步 的 。updateProjectionAsync() 会 更 新 投影 
Reservation 对 象 的 状态 。 但 是 ， 仔 细 看 一 下 updateProjection() 的 实现 方式 ， 很 快 就 
会 发 现 这 里 可 能 会 有 竞 态 条 件 : 两 个 线程 会 消费 不 同 的 事件 ， 但 是 可 能 会 修改 同一 个 
Reservation 并 试图 进行 存储 。 这 样 ， 第 一 个 更 新 会 被 覆盖 掉 ， 状 态 就 丢失 了 。 技 术 上 ， 
可 以 尝试 乐观 锁定 ， 但 是 另外 一 个 问题 依然 存在 : fact 的 顺序 无 法 保证 。 如 有 果 面 临 的 是 两 
个 不 相关 的 Reservation 实例 (具有 不 同 的 UUID)， 那 么 就 不 会 有 这 种 问题 。 但 是 将 多 个 
fact 应 用 到 同一 个 Reservation 时 ， 如 果 应 用 fact 的 顺序 与 它们 实际 发 生 的 顺序 不 一 致 ， 
那么 后 果 将 是 灾难 性 的 。 
这 就 是 groupBy() 能 够 发 挥 作用 的 地 方 。 它 会 基于 基 个 key 将 流 切 分 为 多 个 并 行 流 ， 每 个 
流 包含 具备 给 定 key 的 事件 。 本 例 想 要 将 所 有 关于 预定 信息 的 一 个 fact 大 型 流 切 分 为 很 多 
小 流 ， 每 个 小 流 只 会 发 布 与 特定 UUID 相关 的 事件 ， 如 下 所 示 。 


Observable<ReservationEvent> facts = factStore.observe(); 

















Observable<GroupedObservable<UUID, ReservationEvent>> grouped = 
facts.groupBy(ReservationEvent: :getReservationUuid); 


grouped.subscribe(byUuid -> { 
byUuid.subscribe(this::updateProjection); 


}); 


这 个 样 例 包 含 了 多 个 新 的 构造 。 首 先 ， 得 到 上 游 的 0bservable<ReservationEvent> 并 根据 
UUID (ReservationEvent::getReservationUuid) 对 其 进行 分 组 。 你 可 能 认为 groupBy() 
应 该 会 返回 一 个 List<0bservable<ReservationEvent>> 列表 ， 毕 竟 将 一 个 流转 换 成 了 多 
个 。 但 是 这 种 假设 是 不 能 成 立 的 ， 因 为 groupBy() 无 法 得 知 上 游 的 流 会 生成 多 少 个 不 
同 的 key (UUID)。 因 此 ， 结 果 必 须 是 在 运行 时 生成 的 : 一 发 现 新 的 UUID， 就 发 布 新 的 
Grouped0bservabLe<UUID ， ReservationEvent> 并 推送 这 个 UUID 相关 的 事件 。 所 以 ， 显 而 易 
见 ， 外 层 的 数据 结构 必须 是 0bservable。 

但 是 ， 这 个 Grouped0bservabLe<UUID ，ReservationEvent> 又 是 什么 呢 ? Grouped0bservabtLe 
是 0bservable 的 一 个 简单 子 类 ， 它 与 标准 的 Observable 契约 不 同 ， 它 会 返回 这 个 流 中 
所 有 事件 所 属 的 一 个 key (在 样 例 中 也 就 是 UUID)。 发 布 的 Grouped0bservable 的 数量 范 
围 是 从 一 (这 种 情况 下 所 有 的 事件 具有 相同 的 key) 到 所 有 事件 数量 的 总 和 (如果 上 游 
中 的 每 个 事件 都 有 唯一 的 key)。 在 这 种 情况 下 ， 檬 套 的 0bservable 不 会 像 以 往 那 样 粳 
糕 。 订 阅 外 层 0bservable 时， 发 布 的 每 个 值 实 际 上 是 另外 一 个 可 以 订阅 的 0bservable 
(Grouped0bservable)。 例 如 ， 每 个 内 部 流 可 以 提供 彼此 关联 的 事件 (比如 具有 相同 的 关联 
ID), 但 是 内 部 流 之 间 是 不 相关 的 ， 可 以 分 别 进行 处 理 。 


3.4.3 下 一 步 要 学 习 什 么 
RxJava 内 置 了 很 多 操作 符 ， 其 中 有 一 些 会 在 第 6 章 进行 阅 述 。 但 是 ， 讲 解 所 有 的 API 并 没 
有 太 大 的 意义 ， 并 且 非 常 耗 时 间 。 同 时 ， 这 种 详尽 的 描述 随 着 版 本 更 迄 也 会 过 时 。 但 是 我 
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们 应 该 对 操作 符 可 以 做 什么 ， 以 及 是 如 何 运 行 的 有 一 个 基本 的 了 解 。 接 下 来 让 我 们 学 习 编 
写 自 定义 操作 符 。 


3.5 ”编写 自 定义 的 操作 符 


你 现在 只 是 接触 了 RxJava 可 用 操作 符 中 的 一 些 皮毛 ， 但 本 书 通 篇 学 下 来 ， 你 会 掌握 更 多 
这 方面 的 知识 。 除 此 之 外 ， 操 作 符 真正 的 威力 源 于 它们 的 组 合 。 遵 循 UNIX 小 巧 且 锋利 的 
工具 的 理念 ， 每 个 操作 符 每 次 只 进行 一 个 很 小 的 转换 。 本 节 首 先 会 介绍 compose() 操作 符 ， 
它 能 对 更 小 的 操作 符 进行 流畅 的 组 合 。 随 后 介绍 Lift() 操作 符 ， 借 助 它 能 够 编写 全 新 的 自 
定义 操作 符 。 


3.5.1 借助 compose() 重 用 操作 符 


首先 看 一 个 样 例 。 出 于 某 些 原 因 ， 我 们 需要 转换 一 个 上 游 的 0bservable， 转 换 之 后 只 接收 
偶数 条 目 ， 而 丢弃 所 有 其 他 条 目 。6.1 市 将 会 介绍 buffer() 操作 符 ， 使 用 这 个 操作 符 能 够 
让 该 任务 变 得 非常 简单 (buffer(1，2) 几乎 完全 满足 要 求 )。 但 是 ， 在 以 下 代码 中 先 假 闪 
并 不 知道 这 个 操作 符 ， 通 过 组 合 儿 个 操作 符 也 能 很 容易 地 实现 该 功能 。 


import org.apache.commons.lang3.tuple.Pair; 


















































11... 


Observable<Boolean> trueFalse = Observable.just(true, false).repeat(); 
Observable<T> upstream = //... 
Observable<T> downstream = upstream 

.ZipWith(trueFalse, Pair::of) 

.filter(Pair::getRight) 

.map(Pair: :getLeft); 


首先 ， 样 例 生 成 了 一 个 无 穷 的 0bservabLe<BooLean>， 它 会 交替 发 布 true 和 false。 以 上 代 
码 创 建 了 只 有 两 个 条 目 、 固 定 的 [true，false] 流 ， 然 后 通过 repeat() 操作 符 无 穷 重复 。 
repeat() 会 拦截 上 游 的 完成 通知 ， 拦 截 到 该 通知 之 后 并 不 会 传递 给 下 游 ， 而 是 重新 进行 订 
阅 。 因 此 ，repeat() 操作 符 并 不 能 保证 循环 生成 相同 的 事件 序列 ， 但 是 如 果 上 游 是 一 个 简 
单 的 固定 流 ， 那 么 就 能 重复 生成 相同 的 事件 流 。 参 见 7.1.4 市 ， 了 解 与 之 类 似 的 retry() 操 
作 符 。 


我 们 将 上 游 的 Observable 与 这 个 无 穷 的 true 和 false 流 进 行 zipwith() 操作 。 但 是 ， 压 
缩 操作 需要 组 合 两 个 条 目的 函数 。 在 其 他 语言 中 ， 这 非常 容易 实现 。 在 Java 中 ， 需 要 
借助 Apache Commons Lang 库 ， 它 提供 了 一 个 简单 的 Pair 类 。 此 时 ， 我们 有 了 一 个 用 
Pair<T，Boolean> 值 组 成 的 流 ， 每 个 值 的 右 侧 (Pair 由 左 侧 和 右 侧 组 件 组 成 ) 是 true 或 
false。 下 一 步 ， 使 用 filter() 过 滤 所 有 的 pair， 只 保留 右 侧 为 true 的 条 目 ， 也 就 是 丢 
弃 所 有 偶数 的 patr。 最 后 ， 拆 开 pair 对 象 ， 丢 弃 Boolean 类 型 的 值 ， 只 保留 T 类 型 的 值 
(getLeft() ) 。 如 果 你 不 想 依赖 第 三 方 库 ， 那 么 替换 实现 如 下 所 示 。 







































































注 8: Andrew Hunt 和 David Thoma 编著 的 《程序 员 修 炼 之 道 一 一 从 小 工 到 专家 》。 
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import static rx.0bservabLe.empty; 
import static rx.Observable.just; 


A 


upstream.zipWith(trueFalse, (t, bool) -> 
bool ? just(t) : empty()) 
.flatMap(obs -> obs) 


乍 看 上 去 ，flatMap() 有 些 奇 怪 ， 似 平 没 有 做 任何 重要 的 事情 。zipwith() 转换 之 后 ， 会 返 
回 一 个 Observable (包含 一 个 元 素 或 者 为 空 ) ， 这 会 形成 Observable<0bservable<T>>。 按 
照 这 种 方式 来 使 用 flatMap()， 就 能 避免 代 套 了 。 上 毕竟 fLatMap() 中 的 lambda 表达 式 会 为 
每 个 输入 元 素 返回 一 个 Observable， 这 个 输入 元 素 恰好 也 是 0bservable。 


不 管 你 选择 使 用 哪 种 实现 方式 ， 它 们 都 非常 难以 重用 。 如 果 需 要 重用 每 个 奇数 元 素 组 成 的 
运算 符 序列 ， 你 要 么 复制 -粘贴 这 些 代码 ， 要 么 创建 一 个 如 下 所 示 的 工具 方法 。 


static <T> Observable<T> odd(Observable<T> upstream) { 
Observable<Boolean> trueFalse = just(true, false).repeat(); 
return upstream 
.ZipWith(trueFalse, Pair::of) 
.filter(Pair::getRight) 
.map(Pair::getLeft) 














} 


但 是 ， 这 样 就 无 法 流畅 地 链接 操作 符 了 ， 换 句 话 说 ， 你 不 能 写成 obs.op1().odd().op2() 
了 。 与 C# (这 也 是 Reactive Extensions 起 源 的 地 方 ) 和 Scala (通过 implicits) 不 同 ，Java 
并 不 允许 扩展 方法 。 但 是 ， 内 置 的 compose() 操作 符 实现 了 非常 接近 的 功能 。compose() 接 
收 一 个 函数 作为 参数 ， 这 个 函数 通过 一 系列 的 操作 符 转换 上 游 的 Observable。 以 下 代码 是 
它 在 实践 中 使 用 的 样 例 。 
private <T> Observable.Transformer<T, T> odd() { 
Observable<Boolean> trueFalse = just(true, false).repeat(); 
return upstream -> upstream 
.ZipWith(trueFalse, Pair::of) 
.filter(Pair::getRight) 
.map(Pair::getLeft); 





} 
[in 


//[A, B, C, D, E...] 
Observable<Character> alphabet = 
Observable 
.range(0, 'Z' - 'A' + 1) 
.map(c -> (char) ('A' + c)); 


//[A, C, E, G, I...] 

alphabet 
.Compose(ClassName:odd) 
.forEach(System.out: :println); 


odd() 国 数 会 返回 一 个 Transformer<T，T>， 也 就 是 从 0bservable<T> 到 0bservable<T> ( 当 
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然 ， 类 型 可 以 不 一 样 ) 。 由 于 Transformer 本 身 就 是 一 个 函数 ， 因 此 可 以 将 其 替换 为 lambda 
表达 式 (upstream -> upstream...)。 需 要 注意 ，odd() 国 数 是 在 Observable 组 装 的 时 候 
立即 执行 的 ， 而 不 是 在 订阅 的 时 候 。 有 意思 的 是 ， 如 果 你 想 要 发 布 偶数 值 (第 2 个 、 第 4 
个 、 第 6 个 等 ) 而 不 是 奇数 值 (第 1 个 、 第 3 个 、 第 5 个 等 )， 只 需要 将 trueFalse 替换 为 
trueFalse.skip(1) 即 可 。 


3.5.2 ”使 用 Lift() 实 现 高 级 操作 符 


实现 自 定义 操作 符 是 比较 麻烦 的 事情 ， 因 为 必须 要 考虑 回 压 〈 参 见 6.2 节 ) 和 订阅 机 制 。 
因此 ， 你 最 好 使 用 已 有 的 操作 符 实现 需求 ， 而 不 是 自 定义 操作 符 。 内 置 操作 符 经 过 了 更 好 
的 测试 ， 功 能 也 经 过 了 验证 。 但 是 ， 如 有 果 这 些 操作 符 均 不 满足 要 求 ， 那 么 可 以 借助 Lift() 
元 操作 符 。compose() 只 能 将 已 有 的 操作 符 组 合 在 一 起 ， 而 借助 Lift() 几乎 可 以 实现 任意 
的 操作 符 ， 改 变 上 游 事 件 的 流 。 


compose() 转换 的 是 0Observable， 而 Lift() 转换 的 是 Subscriber。 回 忆 一 下 2.4.1 节 介 绍 
过 的 内 容 ， 我 们 通过 subscribe() 订阅 一 个 0bservable 的 时 候 ， 包 装 回调 的 Subscriber 
实例 会 被 传递 给 它 订阅 的 Observable， 并 且 导 致 Obsevable 的 create() 方法 被 调用 ， 在 
调用 时 subscriber 会 作为 参数 传递 进来 (简单 概述 )。 所 以 ， 我 们 每 次 订阅 的 时 候 ， 一 个 
Subscriber 就 会 通过 所 有 的 操作 符 传递 到 原始 的 Observable 上。 显然 ， 在 Observable 和 
subscribe() 之 间 ， 可 能 会 有 任意 数量 的 操作 符 ， 它 们 会 改变 流 往 下 游 的 事件 ， 如 下 所 示 。 
Observable 

.range(1, 1000) 

.filter(x -> x % 3 == 0) 

.distinct() 

.reduce((a, xX) -> a + X) 


.map(Integer::toHexString) 
.Subscribe(System.out::println); 


但 是 ， 这 里 有 个 很 有 意思 的 事实 : 如 果 你 查阅 RxJava 的 源码 ， 并 将 操作 符 的 调用 替换 为 
它们 的 方法 体 ， 这 个 非常 复杂 的 操作 符 序列 看 上 去 就 非常 有 规律 了 (请 注意 reduce() 是 如 
何 通 过 scan().takeLast(1).single() 实现 的 )。 
















































































Observable 
.range(1, 1000) 
.lift(new OperatorFilter<>(x -> x % 3 == 0)) 
.lift( OperatorDistinct.<INnteger>instance()) 
.lift(new OperatorScan<>((Integer a, Integer x) -> a + x)) 
.lift( OperatorTakeLastOne.<Integer>instance()) 
.lift( OperatorSingle.<Integer>instance()) 
.lift(new OperatorMap<>(Integer::toHexString)) 
.Subscribe(System.out::println); 


除了 一 次 操作 多 个 流 的 操作 符 〈 如 flLatMap())， 几 乎 所 有 的 操作 符 都 是 通过 Lift() 的 方 
式 实 现 的 。 在 最 底层 调用 subscribe() 的 时 候 ，RxJava 会 创建 一 个 Subscriber<String> 
实例 并 将 其 传递 到 直接 父 节 点 。 这 可 能 是 “真正 ”发 布 事件 的 0bservabte<String>， 也 
可 能 只 是 某 些 操作 符 的 结果 ， 比 如 样 例 中 的 map(Integer::toHexString)。map() 本 身 
并 不 会 发 布 事件 ， 但 是 它 会 接收 一 个 subscriber 实例 ， 而 这 个 实例 是 想 接收 事件 的 。 
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map() 做 的 事情 (通过 Lift() 就 是 透明 地 订阅 其 父 操作 符 (在 上 面 的 样 例 
中 ， 也 就 是 reduce())。 但 是 ， 它 不 能 原样 传递 它 接 收 到 的 Subscriber 实例 。 这 是 因为 
Subsecbe 二 需要 We 而 reduce() 预期 得 到 的 是 Subscriber<Integer>。 

这 恰好 对 应 map() 做 的 事情 : 将 Integer 转换 为 String。 因 此 ，map() 操作 符 会 创建 一 个 
新 的 人 工 Subscriber<Integer>， 每 次 这 个 特殊 的 Subscriber 接收 到 事件 ， 它 就 会 调用 
Integer: :toHexString 国 数 并 通知 下 游 的 Subscriber<String>。 


1. 探究 map() 操 作 符 的 内 部 原理 

OperatorMap 类 会 完成 这 样 的 事情 : 提供 一 个 从 下 游 (child) Subscriber<R> 到 上 游 
Subscriber<T> 的 转换 。 如 下 代码 展现 了 RxJava 中 的 实际 实现 ， 其 中 做 了 一 些 易 读 性 方面 
的 简化 。 


public final class OperatorMap<T, R> implements Operator<R, T> { 


























private final Func1<T，R> transformer; 


public OperatorMap(Func1i<T, R> transformer) { 
this.transformer = transformer; 


3 


@Override 
public Subscriber<T> call(final Subscriber<R> child) { 
return new Subscriber<T>(child) { 


@Override 

public void onCompleted() { 
child.onCompleted(); 

} 


@Override 
public void onError(Throwable e) { 
child.onError(e); 


} 
@Override 
public void onNext(T t) { 
try { 
child.onNext(transformer .call(t)); 
} catch (Exception e) { 
onError(e); 
} 
} 


}; 
} 


这 里 有 个 值得 注意 的 细节 ， 那 就 是 T 和 R 泛 型 的 顺序 发 生 了 反 转 。map() 操作 符 会 将 上 游 
T 类 型 的 值 转换 为 R 类 型 。 但 是 ， 操 作 符 的 责任 是 将 Subscriber<R> (来 自 下 游 的 订阅 ) 转 
换 为 Subscriber<T> (传递 给 上 游 的 Observable)。 我 们 期 望 的 是 通过 Subscriber<R> 订阅 ， 
而 map() 被 用 来 对 付 0bservabLe<T>， 因 此 需要 Subscriber<T>。 
































请 确保 你 已 经 基本 理解 了 上 述 RxJava 源 代码 中 的 代码 片段 。 理 解 map() 是 如 何 实现 的 (这 
是 公认 的 最 简单 的 操作 符 之 一 ) 能 够 帮助 你 编写 自己 的 操作 符 。 每 次 使 用 map() 操作 一 个 
六 时 ， 实 际 上 是 使 用 一 个 新 的 0peratorMap 实例 来 调用 Lift() 并 提供 transformer 国 数 。 
这 个 函数 会 操作 上 游 T 类 型 的 事件 并 为 下 游 返回 R 类 型 的 事件 。 每 次 用 户 为 你 的 操作 符 提 
供 任何 自 定义 的 函数 / 转换 时 ， 请 确保 捕获 到 所 有 预期 之 外 的 异常 并 将 它们 通过 onError() 
转发 到 下 游 。 这 样 也 能 够 确保 你 会 取消 对 上 游 流 的 订阅 ， 避 免 进 一 步 发 布 事件 。 

在 有 人 真正 订阅 之 前 ， 我 们 在 底层 几乎 不 会 创建 引用 0peratorMap 实例 的 新 0bservabte 
(Lift() 与 其 他 的 操作 符 类 似 ， 也 会 创建 新 的 Observable)， 而 0peratorMap 实例 反 过 会 持 
有 对 函数 的 引用 。 但 是 ,一 旦 有 人 真正 订阅 ，0peratorMap 的 caLL() 函数 就 会 被 调用 。 这 
个 函数 会 接收 到 Subscriber<String> (例如 ， 包 装 System.out::println) 并 返回 另 一 个 
Subscriber<Integer>。 后 一 个 Subscriber 会 遍历 上 游 的 流 来 进行 处 理 。 


这 几乎 就 是 所 有 操作 符 的 运行 原理 ， 无 论 是 内 置 的 ， 还 是 自 定 义 的 。 它 们 接收 一 个 Subscriber 
并 返回 另外 一 个 Subscriber， 对 事件 进行 增强 并 传递 下 游 Subscriber 想 要 的 任何 东西 。 


2. 第 一 个 操作 符 
我 们 想 要 实现 一 个 操作 符 ， 这 个 操作 符 能 够 发 布 每 个 奇数 元 素 (第 1 个 、 第 3 个 、 第 5 个 
等 ) 的 tostring() 值 。 如 下 所 示 。 
Observable<String> odd = Observable 
.range(1, 9) 
.lift(toSstringofO0dd()) 
// 将 会 发 布 字符 串 "1"，"3"，"5"，"7" 和 "9" 
其 实 ， 你 可 以 使 用 内 置 的 操作 符 完成 相同 的 功能 ， 只 是 出 于 教学 目的 才 编 写 以 下 自 定义 操 
作 符 的 代码 。 
Observable 
.range(1, 9) 
.buffer(1, 2) 


.concatMapIterable(x -> x) 
.map(Object: :toString); 


buffer() 操作 符 会 在 6.1.2 节 进 行 介绍 ， 现 在 你 需要 知道 的 就 是 buffer(1，2) 会 将 任意 的 
Observable<T> 转换 为 Observable<List<T>>， 而 每 个 内 部 的 List 都 只 有 一 个 奇数 元 素 ， 跳 过 
了 偶数 元 素 。 在 拥有 了 List(1)、List(3) 等 列表 组 成 的 流 之 后 ， 使 用 concatMapIterable() 
将 其 重 构 为 一 个 饥 平 化 的 流 。 但 是 出 于 教学 的 目的 ， 让 我 们 实现 一 个 自 定义 的 操作 符 ， 通 过 
一 步 操作 完成 这 项 任务 。 自 定义 操作 符 会 处 于 以 下 两 种 状态 中 的 某 一 种 。 

它 从 上 游 流 中 得 到 奇数 事件 (第 1 个 、 第 3 个 、 第 5 个 等 ) 时 ， 会 在 调用 tostring() 

之 后 将 其 转发 到 下 游 中 。 

它 从 上 游 流 中 得 到 偶数 事件 时 ， 丢 弃 即 可 。 
然后 ， 不 断 重复 这 个 过 程 。 这 个 操作 符 大 致 如 下 所 示 。 


<T> 0bservabLe.0perator<String，T> toStringof0dd() { 
return new Observable.Operator<String, T>() { 





































































































private boolean odd = true; 
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@Override 
public Subscriber<? super T> call(Subscriber<? super String> child) { 
return new Subscriber<T>(child) { 
@Override 
public void onCompLeted() { 
child.onCompleted(); 
} 


@Override 
public void onError(Throwable e) { 
child.onError(e); 


} 
@Override 
public void onNext(T t) { 
if(odd) { 
child.onNext(t.toString()); 
} elsef{ 
request(1); 
odd = !odd; 
} 


2 
站 
}; 
} 
对 request(1) 的 调用 将 在 6.2.4 节 进 行 介绍 。 现 在 你 可 以 这 样 理解 : Subscriber 请 求 事件 
的 一 个 子 集 时 ， 比 如 只 取 前 两 个 (take(2))，RxJava 在 内 部 会 通过 调用 request(2) 只 请 求 
符合 该 数量 的 数据 。 这 个 请 求 会 传递 给 上 游 ， 我 们 就 会 只 得 到 1 和 2。 这 里 会 丢弃 2 ( 偶 
数 )， 但 是 又 必须 要 为 下 游 提 供 两 个 事件 ， 因 此 ， 需 要 请 求 一 个 额外 的 事件 (request(1)) 
并 添加 进来 ， 这 样 就 会 得 到 3。RxJava 实现 了 一 个 非常 复杂 的 名 为 回 压 的 机 制 ， 这 种 机 制 
允许 订阅 者 只 请 求 符 合 其 处 理 能 力 的 事件 ， 避 免 生产 者 的 输出 超过 消费 者 的 处 理 能 力 。6.2 
节 将 会 讨论 这 个 话题 。 
在 RxJava 中 ，nultLtL 是 一 个 合法 的 事件 ， 这 其 实说 不 上 是 好 事 还 是 坏事 。 也 
就 是 说 ，0bservable.just("A"，null，"B") 会 像 其 他 流 一 样 正常 运行 。 在 设 
计 自 定义 操作 符 和 使 用 操作 符 的 时 候 ， 你 需要 考虑 这 一 点 。 但 是 ， 传 递 null 
通常 被 视 为 不 符合 习惯 用 法 ， 你 应 该 使 用 包装 值 类 型 来 进行 替代 。 









































另外 一 个 可 能 出 现 的 很 有 意思 的 缺陷 ， 就 是 无 法 将 子 Subscriber 作为 参数 传递 给 新 的 
Subscriber， 如 下 所 示 。 


<T> 0bservabLe.0perator<String，T> toStringof0dd() { 
// 有 问题 的 


return child -> new Subscriber<T>() { 


/11... 





Subscriber 这 个 无 参 的 构造 函数 能 够 正常 运行 ， 操 作 符 的 运行 似乎 也 没有 问题 。 但 是 ， 看 
一 下 在 多 到 无 穷 流 时 会 发 生 什么 ， 如 下 所 示 。 
Observable 

.range(1, 4) 

.repeat() 

.Lift(toStringof0dd()) 

.take(3) 

.Subscribe( 

System.out: :println, 

Throwable: :printStackTrace, 

() -> System.out.println("Completed") 

); 


我 们 构造 了 一 个 会 发 布 C4、"2"、"3"、"4"、"4"、"2"、"3",..) 的 无 穷 数字 流 ， 应 用 操 
作 符 ("1"、"3"、"1"、"3"...)， 并 只 取 前 三 个 值 。 这 完全 没有 问题 ， 也 不 应 该 会 失败 ， 毕 
竟 流 是 延迟 执行 的 。 但 是 ， 从 new Subscriber(chiLd) 构造 函数 中 移 除 child，0bservable 
在 接收 到 1、3、1 后 并 没有 发 出 完成 的 通知 。 这 里 到 底 发 生 了 什么 呢 ? 


take(3) 操作 符 只 会 请 求 前 三 个 值 ， 并 且 在 此 之 后 想 要 调用 unsubscribe()。 令 人 遗憾 的 
是 ， 取 消 订 阅 的 请 求 并 不 会 被 发 送 到 原始 的 流 上 ， 这 样 原始 的 流 会 持续 生成 值 。 更 糟糕 
的 是 ， 这 些 值 会 被 自 定义 操作 符 处 理 并 传递 给 下 游 Subscriber (take(3))， 而 下 游 其 实 已 
经 不 再 监听 了 。 先 将 实现 细节 放 到 一 边 ， 根 据 经 验 ， 在 编写 自 定义 操作 符 时 ， 要 将 下 游 
Subscriber 作为 构造 函数 的 参数 传递 给 新 的 Subscriber。 无 参 构造 函数 很 少 被 用 到 ， 简 单 
的 操作 符 也 不 太 需 要 它 。 


在 编写 自 定义 操作 符 代 码 时 ， 这 些 问 题 仅仅 是 冰山 一 角 而 已 。 幸 而 ， 我 们 通过 内 置 的 机 制 
能 够 实现 绝 大 多 数 的 场景 。 


3.6 小结 


RxJava 真正 的 威力 在 于 它 的 操作 符 。 数 据 流 的 声明 式 转换 是 非常 安全 的 ， 并 且 具 有 表述 
性 和 灵活 性 。 凭 借 函 数 式 编程 强大 的 用 户 基 础 ， 在 评估 是 否 采用 RxJava 时 ， 操 作 符 起 决 
定性 的 作用 。 和 掌握 内 置 操作 符 是 成 功 使 用 这 个 库 的 关键 。 本 章 没 有 把 所 有 的 操作 符 都 介绍 
到 ，6.1 方 将 会 介绍 更 多 内 容 。 但 是 ， 到 目前 为 止 ， 你 应 该 对 RxJava 能 够 做 什么 ， 以 及 当 
它 不 能 直接 完成 某 些 任务 时 该 如 何 进行 增强 有 整体 的 了 解 。 
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第 4 章 


将 反应 式 编程 应 用 于 已 有 应 用 程序 





托 马 什 : 努 尔 凯 维 茨 〈Tomasz Nurkiewicz) 


不 管 是 全 新 的 应 用 程序 还 是 遗留 的 代码 库 ， 如 果 要 引入 新 的 库 、 技 术 或 范式 ， 都 需要 经 过 仔 
细 的 考虑 ，RxJava 也 不 例外 。 本 章 将 回顾 普通 Java 应 用 程序 中 的 一 些 模式 和 架构 ， 看 看 Rx 
应 该 如 何 提供 帮助 。 这 个 过 程 并 不 简单 ， 需 要 转变 思维 方式 ， 小 心地 从 命令 式 转换 为 函数 式 
和 反应 式 风 格 。 目 前 ，Java 项 目 中 的 很 多 库 只 是 让 应 用 程序 膨胀 ， 但 是 并 设 有 带 来 太 大 的 回 
报 。 在 本 章 中 ， 你 将 了 解 到 RxJava 如 何 简化 传统 项 目 ， 以 及 它 为 遗留 平台 带 来 的 收益 。 
相信 你 已 经 对 RxJava 非常 兴奋 了 。 内 置 的 操作 符 和 简洁 性 使 得 Rx 成 为 进行 事件 流转 换 的 
强大 工具 。 但 是 ， 如 果 明 天 到 办 公 室 ， 你 会 发 现 工 作 环境 中 没有 流 ， 也 没有 来 自 证 券 交易 
所 的 实时 事件 。 你 在 应 用 程序 中 很 难 找 到 事件 ， 它 只 是 Web 请 求 、 数 据 库 和 外 部 API 的 
混合 物 。 你 迫不及待 地 想 要 将 新 的 RxJava 用 到 某 个 地 方 ， 而 不 是 简单 的 Hello world。 但 
是 ,现实 生活 中 看 起 来 并 没有 适合 使 用 Rx 的 用 例 。 不 过 ， 在 架构 一 致 性 和 健壮 性 方面 ， 
RxJava 被 视 为 重要 的 进步 。 你 不 必 彻 底 采 用 反应 式 风 格 ， 这 样 风险 太 大 ， 并 且 需 要 大 量 的 
前 期 工作 。 但 是 ，Rx 可 以 在 任意 层 中 引入 ， 而 不 会 破坏 整个 应 用 程序 。 


本 章 将 介绍 一 些 通用 的 应 用 程序 模式 和 方式 。 借 助 它们 ， 你 可 以 使 用 RxJava 以 非 侵入 的 
方式 增强 应 用 程序 ， 这 里 需要 重点 关注 数据 库 查 询 、 缓 存 、 错 误 处 理 和 周期 性 的 任务 。 你 
在 栈 的 不 同位 置 添加 的 RxJava 越 多 ， 架 构 就 会 越 一 致 。 


4.1 从 集合 到 0bservable 


除非 平台 是 基于 近期 的 JVM 框架 构建 的 ， 如 Play、Akka Actors 或 Vert.x， 否 则 你 的 栈 很 
可 能 一 面 是 Servlet 容器 ， 另 一 面 是 JDBC 或 Web Service。 在 这 两 者 之 间 ， 会 有 不 同 数 量 
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的 层 实现 业务 逻辑 。 我 们 不 会 一 次 性 全 部 重 构 这 些 层 ， 而 是 从 一 个 简单 的 样 例 开 始 。 下 画 
的 类 代表 了 一 个 简单 的 存储 库 (repository) ， 它 将 我 们 从 数据 库 中 抽取 了 出 来 。 


class PersonDao { 
































List<Person> listPeople() { 
return query("SELECT * FROM PEOPLE"); 
} 


private List<Person> query(String sql) { 
/Ss 
} 


} 


先 将 实现 细节 放 到 一 边 ， 以 上 代码 与 Rx 有 什么 关系 呢 ?” 到 目前 为 止 ， 我们 讨论 了 上 游 系 
统 推送 过 来 的 异步 事件 ， 还 涉及 了 对 它们 的 订阅 。 这 个 普通 的 Dao 是 如 何 与 此 相关 联 的 ? 
Observable 不 仅 是 将 事件 推送 至 下 游 的 管道 。 你 可 以 将 0bservable<T> 视 为 一 个 数据 结构 ， 
与 Iterable<T> 相对 应 。 它 们 都 持 有 T 类 型 的 条 目 ， 但 是 提供 了 完全 不 同 的 接口 。 所 以 ， 
你 能 够 很 容易 地 对 它们 进行 互 换 ， 这 不 足 为 奇 。 
Observable<Person> listPeople() { 
final List<Person> people = query("SELECT * FROM PEOPLE"); 


return Observable.from(people); 


} 


我 们 对 已 有 的 API 进行 了 重大 变更 。 根 据 系统 规模 的 不 同 ， 这 种 不 兼容 性 可 能 是 一 个 大 问 
题 。 因 此 ， 应 该 尽快 将 RxJava 引入 到 你 的 API。 显 然 ， 这 里 使 用 的 是 已 有 的 应 用 程序 ， 因 
此 这 种 思路 并 不 可 行 。 


4.2 ”BlockingObservable: 脱离 反应 式 的 世界 


如 果 你 将 RxJava 与 已 有 的 、 阻 塞 式 的 、 命 令 式 的 代码 组 合 人 使用， 那么 可 能 需要 将 
Observable 转换 为 简单 的 集合 。 这 种 转换 令 人 非常 不 夹 ， 它 需要 在 Observable 上 阻塞 ,等 
待 它 的 完成 。 在 0bservable 完成 之 前 ， 无 法 创建 集合 。BlockingObservable 是 一 个 特殊 的 
类 型 借助 它 能 够 很 容易 地 在 非 反 应 式 环境 中 使 用 0bservable。 在 使 用 RxJava 的 时 候 ， 
BlockingObservable 应 该 是 最 后 的 选择 ， 但 是 在 组 合 阻塞 代码 和 非 阻塞 代码 时 ， 它 必 不 可 少 。 


我 们 在 第 3 章 重 构 过 listPeople() 方 法， 让 它 返 回 0Observable<People> 而 不 是 List。 从 
任何 意义 上 来 讲 ，0bservable 都 不 是 Iterable， 所 以 代码 无 法 编译 通过 。 我 们 想 要 循序 渐 
进 ， 而 不 想 进 行 大 规模 的 重 构 ， 所 以 变更 的 范围 越 小 越 好 。 客 户 端 代码 可 能 会 如 下 所 示 。 


List<Person> people = pesonDao.listPeople(); 
String json = marshal(people); 


我 们 可 以 将 marshal() 想象 为 从 people 集合 拉 取 (pull) 数据 ， 并 将 它们 序列 化 为 
JSON。 事 实 上 ， 情 况 不 再 是 这 样 了 ， 我 们 不 能 在 需要 时 简单 地 从 0bservable 中 拉 取 条 
目 。0bservablte 负责 生成 (推送 ) 条 目 ， 并 且 如 果 有 订阅 者 的 话 ， 还 会 通知 他 们 。 这 种 
根本 性 的 变化 很 容易 通过 BlockingObservable 来 规避 。 这 个 非常 便利 的 类 完全 独立 于 
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Observable， 能 够 通过 0bservable.toBlocking() 方法 获取 。 阻 塞 变种 的 0bservabLe 有 着 
表面 上 类 似 的 方法 ， 比 如 single() 或 subscribe()。 但 是 ， 在 没有 为 异步 Observable 做 好 
准备 的 阻塞 环境 中 ，BLockingobservabtLe 要 便利 得 多 。BlockingObservable 上 的 操作 符 一 
般 会 阻塞 (等待)， 直 到 底层 的 0bservable 完成 。 这 与 Observable 中 的 主要 概念 严重 冲突 ， 
即 所 有 操作 都 是 异步 、 延 迟 、 动 态 执行 的 。 例 如 ，0bservabte.forEach() 会 异步 接收 来 自 
Observable 的 事件 ， 但 是 BLockingobservabtLe.forEach() 会 发 生 阻 蹇 ， 直 到 处 理 完 所 有 事件 
并 完成 流 。 同 时 ， 异 常 也 不 再 以 值 (事件 ) 的 方式 进行 传递 ， 而 是 在 调用 线程 中 重新 抛 出 。 


在 以 下 案例 中 ， 我 们 想 要 将 0Observable<Person> 转换 为 List<Person>， 从 而 限制 重 构 的 
范围 。 

Observable<Person> peopleStream = personDao.listPeople(); 

Observable<List<Person>> peopLeList = peopleStream.toList(); 


BlockingObservable<List<Person>> peopleBlocking = peopLeList.toBLocking(); 
List<Person> people = peopleBlocking.single(); 


为 了 阐述 代码 在 执行 过 程 中 都 发 生 了 什么 ， 我 有 意 显 式 保留 了 所 有 的 中 间 状 态 。 在 重 构 
为 Rx 之 后 ，API 返回 的 是 Observable<Person> peopleStream。 这 个 流 可 能 是 完全 反应 
式 、 异 步 和 事件 驱动 的 ， 这 与 我 们 的 需求 完全 不 匹配 : 我 们 需要 的 是 静态 的 List。 第 一 
步 ， 将 Observable<Person> 转换 为 Observable<List<Person>>。 这 个 延迟 执行 的 操作 符 会 
在 内 存 中 缓冲 所 有 的 Person 事件 ， 直 到 接收 到 onCompleted() 事件 。 此 时 ， 将 会 发 布 一 个 
List<Person> 类 型 的 事件 ， 其 中 包含 了 所 有 可 见 的 事件 ， 如 图 4-1 的 弹 珠 图 所 示 。 
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所 形成 的 流 在 发 布 完 一 个 List 条 目 之 后 立即 完成 。 同 样 ， 这 个 操作 符 是 异步 的 ， 它 
并 不 会 等 待 所 有 的 事件 ， 而 是 以 延迟 执行 的 方式 缓冲 所 有 的 值 。 看 上 去 有 些 怪异 的 
Observable<List<Person>> peopleList 随后 被 转换 成 了 BlockingObservable<List<Person>> 
peopleBlocking。 只 有 必须 为 异步 Observable 提供 阻塞 、 静 态 视图 的 时 候 ， 才 应 该 使 
用 BLockingobservabLe。0bservabtLe.from(List<T>) 会 将 基于 拉 取 模式 的 集合 转换 为 
Observable， 而 toBLocking() 做 的 事情 恰好 相反 。 你 可 能 会 问 为 什么 要 为 阻塞 和 非 阻 塞 
操作 符 提供 两 个 抽象 。RxJava 的 作者 指出 ， 明 确 底层 操作 符 的 同步 和 异步 特征 非常 重要 ， 
只 依赖 JavaDoc 是 靠不住 的 。 使 用 两 个 完全 不 相关 的 类 型 能 够 确保 始终 使 用 的 都 是 恰当 
的 数据 结构 。 除 此 之 外 ，Blocking0bservable 应 该 是 你 最 后 的 “武器 "。 正 常情 况 下 ， 你 
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应 该 尽 可 能 长 地 组 合 和 链接 普通 的 observabLe。 但 是 ， 为 了 完成 这 个 练习 ， 让 我 们 先 从 
Observable 退出 来 。 最 后 一 个 操作 符 single() 会 丢弃 所 有 的 0bservabLe， 并 抽取 有 且 仅 有 
的 一 个 条 目 ， 这 个 条 目 预期 从 BLockingobservabtLe<T> 接收 。 类 似 的 操作 符 first() 会 返回 
T 类 型 的 值 并 丢弃 剩余 的 内 容 。 而 single() 在 结束 之 前 要 确保 底层 的 0bservablte 不 会 有 正 
在 等 待 的 事件 。 这 意味 着 single() 会 阻塞 等 待 onCompleted() 回调 。 如 下 展示 了 和 前 述 代 
码 功能 相同 的 片段 ， 只 不 过 这 一 次 将 所 有 的 操作 符 都 链接 了 起 来 。 
List<Person> people = personDao 
.listPeople() 
.toList() 


.toBlocking() 
.Single(); 


你 可 能 认为 以 上 代码 只 是 封装 和 拆 封 Oobservable， 而 没有 特别 明确 的 目的 。 但 是 ， 这 只 是 
第 一 步 。 下 一 个 转换 将 会 引入 一 些 延 迟 执行 的 功能 。 现 在 的 代码 总 是 执行 query("...") 并 
使 用 0bservable 对 其 进行 包装 。 按 照 定义 ，0bservable 是 延迟 执行 的 (尤其 是 cold 类 型 
的 Observable)。 如 果 没 有 人 订阅 ， 它 们 只 代表 不 会 发 布 任何 值 的 流 。 大 多 数 情 况 下 ， 你 
可 以 调用 返回 0bservable 的 方法 ， 而 且 只 要 你 不 订阅 ， 任 何 工作 都 不 会 做 。0bservable 
类 似 于 Future， 因 为 它 承 诺 未 来 会 出 现 一 个 值 。 但 是 ， 只 要 你 不 发 出 请 求 ，cold 类 型 的 
Observable 其 至 不 发 布 值 。 从 这 个 角度 来 说 ，0bservable 更 加 类 似 于 java.util.function. 
Supplier<T>， 即 按 需 生成 T 类 型 的 值 。hot 类 型 的 0bservable 与 之 不 同 ,不管 你 是 否 监 
听 ， 它 都 会 发 布 值 ， 但 是 现在 我 们 先 不 考虑 这 种 类 型 。 仅 仅 存 在 0bservable 并 不 意味 着 会 
有 后 台 任 务 或 副作用 ， 这 与 Future 不 同 ，Future 几乎 总 是 意味 着 有 某 些 并 发 操作 在 执行 。 


4.3 拥抱 延迟 执行 


那么 ， 如 何 让 0bservable 变 成 延迟 执行 的 呢 ? 最 简单 的 技术 就 是 使 用 defer() 对 立即 执行 
的 observable 进行 包装 ， 如 下 所 示 。 
public Observable<Person> listPeople() { 


return Observable.defer(() -> 
Observable.from(query("SELECT * FROM PEOPLE"))); 







































































} 


Observable.defer() 会 接收 一 个 lambda 表达 式 (工厂 )， 这 个 表达 式 会 生成 Observable。 
底层 的 Observable 是 立即 执行 的 ， 所 以 我 们 想 延 迟 它 的 创建 。defer() 直到 最 后 一 刻 才 会 
实际 创建 observable， 即 有 人 订阅 它 的 时 候 。 这 意味 着 会 有 一 些 很 有 意思 的 事情 。 因 为 
Observable 是 延迟 执行 的 ， 所 以 调用 ListPeople() 不 会 有 什么 副作用 ， 也 几乎 没有 性 能 
损耗 。 此 时 ， 还 没有 进行 数据 库 查 询 。 你 可 以 将 Observable<Person> 视 为 一 个 承诺 ， 但 是 
还 没有 进行 任何 后 台 处 理 。 注 意 ， 此 时 没有 涉及 异步 行为 ， 仅 仅 是 延迟 执行 。 这 类 似 于 在 
Haskell 编程 语言 中 ， 值 会 延迟 到 绝对 需要 的 时 候 才 进 行 计 算 。 

如 果 你 以 前 从 来 没有 使 用 过 函数 式 语言 进 行 编程 ， 可 能 会 不 理解 为 何 延 迟 执 行 如 此 重要 、 
如 此 有 具有 颠覆 性 。 事 实证 明 ， 这 种 行为 非常 有 用 ， 可 以 大 大 提高 功能 实现 的 质量 和 自由 
度 。 例 如 ， 你 不 再 需要 关注 要 获取 哪些 资源 以 及 何 时 以 何 种 顺序 获取 。RxJava 只 会 在 绝对 
需要 时 才 加 载 它 们 。 
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比如 ， 我 们 都 见 过 如 下 的 后 备 回 退 (fallback) 机 制 。 


void bestBookFor(Person person) { 
Book book; 
try { 
book = recommend(person); 
} catch (Exception e) { 
book = bestSeller(); 





} 
display(book.getTitle()); 


} 


void display(String title) { 
/fi 
} 


你 可 能 觉得 这 样 的 构造 并 没有 什么 问题 。 在 本 例 中 ， 我 们 想 要 为 某 个 人 推荐 最 好 的 图 书 ， 
但 是 如 果 失 败 ， 则 优雅 降级 ， 为 其 展现 最 畅销 的 图 书 。 这 里 的 假设 前 提 是 获取 最 畅销 图 书 
更 快 ， 而且 可 以 进行 缓存 。 但 是 ， 如 果 能 够 声明 式 地 添加 错误 处 理 ，try-catch 代码 块 就 
不 会 混淆 真正 的 逻辑 了 吗 ? 


void bestBookFor(Person person) { 
Observable<Book> recommended = recommend(person); 
Observable<Book> bestSeller = bestSeller(); 
Observable<Book> book = recommended.onErrorResumeNext(bestSeller); 
Observable<String> title = book.map(Book::getTitle); 
title.subscribe(this::display); 



























































} 


到 目前 为 止 ， 我 们 只 是 探索 RxJava 的 用 法 ， 所 以 将 所 有 的 中 间 值 和 类 型 都 保留 了 下 来 。 
在 实际 中 ，bestBookFor() 可 能 会 如 下 所 示 。 


void bestBookFor(Person person) { 
recommend(person) 
.ONErrorResumeNext(bestSeller()) 
.map(Book: :getTitle) 
.Subscribe(this::display); 





} 


这 段 代码 简洁 易 懂 。 首 先 为 person 寻找 推荐 图 书 。 如 果 出 现 错误 (onErrorResumeNext)， 
就 按照 畅销 图 书 的 逻辑 来 进行 处 理 。 不 管 哪个 获得 成 功 ，map 都 会 返回 图 书 的 标题 ， 然 后 
将 其 展现 出 来 。onErrorResumeNext() 是 一 个 非常 强大 的 操作 符 ， 它 会 拦截 上 游 中 的 异常 ， 
将 这 些 异 常 吞噬 并 订阅 提供 的 备用 0bservable。 这 就 是 Rx 实现 try-catch 子 句 的 方式 。 本 
书 将 会 在 后 面 对 错 误 处 理 部 分 进行 详细 介绍 (参见 7.1.2 节 )。 有 目前 只 需 注意 我 们 是 如 何 延 
述 对 bestseller() 的 调用 的 ， 这 样 就 不 用 担心 在 真正 的 图 书 推荐 功能 正常 运行 的 情况 下 ， 
系统 还 会 去 获取 畅销 图 书 。 


4.4 ”组 合 Observable 


SELECT * FROM PEOPLE 并 不 是 最 先进 的 SQL 查询 。 首 先 ， 不 应 该 盲目 地 抓 取 所 有 的 列 ， 但 
是 抓 取 所 有 的 行 更 具 破 坏 性 。 我 们 的 旧 API 不 能 对 结果 进行 分 页 ， 只 能 查看 表 的 一 个 子 
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集 。 在 传统 的 企业 级 应 用 程序 中 ， 它 可 能 会 如 下 所 示 。 


List<Person> listPeople(int page) { 
return query( 
"SELECT * FROM PEOPLE ORDER BY id LIMIT ? OFFSET ?"， 
PAGE_SIZE, 
page * PAGE_SIZE 





); 

} 
本 书 并 不 是 一 本 关于 SQL 的 书 ， 所 以 先 将 实现 的 细节 放 到 一 边 。 这 个 API 的 作者 非常 无 
情 : 我 们 疫 有 选择 记录 范围 的 自由 ， 只 能 从 基于 零 的 页 面 编号 进行 操作 。 但 是 ， 在 RxJava 
中 ， 借 助 延迟 执行 ， 我 们 能 够 模拟 从 给 定 页 开始 读 取 整个 数据 库 的 过 程 。 


import static rx.Observable.defer; 
import static rx.0bservabLe.from; 

















Observable<Person> aLLPeopLe(int initialpage) { 
return defer(() -> from(listPpeople(initialpage))) 
.COoncatWith(defer(() -> 
allPeople(initialPage + 1))); 
} 


这 个 代码 片段 会 延迟 加 载 数据 库 记 录 的 初始 页 ， 比 如 获取 10 个 条 目 。 如 果 没 有 人 订 
阅 ， 甚 至 连 第 一 个 查询 都 不 会 被 调用 。 如 果 有 一 个 订阅 者 只 消费 初始 的 几 个 元 素 (比如 ， 
allPeople(0).take(3))，RxJava 将 会 自动 取消 对 流 的 订阅 ， 也 不 会 执行 进一步 的 查询 。 那 
么 ， 假 设 请 求 11 个 条 目 ， 而 第 一 次 调用 ListPeople() 仅 能 返回 10 个 条 目 ， 此 时 会 怎样 ? 
RxJava 断定 初始 的 Observable 已 经 耗 尽 ， 而 消费 者 依然 没有 得 到 满足 。 垃 好， 它 看 到 了 
concatWith() 操作 符 。 这 就 相当 于 说 : 当 左 侧 的 Observable 完成 时 ， 并 不 会 将 完成 通知 传 
递 给 下 游 ， 而 是 订阅 右 侧 的 0Observable， 就 像 什么 事情 都 没有 发 生 过 一 样 ， 继 续 执行 后 续 
的 逻辑 ， 如 图 4-2 的 弹 珠 图 所 示 。 

















concat 
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图 4-2 
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换 句 话说 ，concatwith() 能 够 将 两 个 Observable 连接 在 一 起 ， 所 以 当 第 一 个 Observable 
完成 的 时 候 ， 第 二 个 Observable 就 会 接替 它 的 位 置 。 在 a.concatWith(b).subscribe(...) 
中 ， 订 阅 者 首先 会 接收 来 自 a 的 所 有 事件 ， 然 后 再 接收 来 自 b 的 所 有 事件 。 在 本 例 中 ， 订 
阅 者 首先 会 接收 初始 的 10 个 条 目 ， 然 后 接收 后 续 的 10 个 。 但 是 ， 仔 细 观 察 ， 代 码 中 有 
一 个 无 穷 递 归 |! allPeople(initialPage) 会 调用 allPeople(initialPage + 1)， 并 且 没 有 
任何 的 停止 条 件 。 在 大 多 数 语言 中 ， 这 意味 着 可 能 会 出 现 Stack0verflowError， 但 是 这 
里 并 不 会 。 同 样 ， 对 allPeople() 的 调用 经 常 是 延迟 的 ， 因 此 停止 监听 (取消 订阅 ) 的 时 
候 ， 弟 归 也 就 停止 了 。 从 技术 上 讲 ，concatwith() 依然 有 可 能 会 导致 StackOverflowError。 
6.2.4 节 会 介绍 如 何 处 理 对 传人 数据 的 不 同 需求 。 

延迟 加 载 数 据 块 的 技术 是 非常 有 用 的 ， 它 能 让 你 专注 于 业务 逻辑 ， 而 不 必 关 心底 层 细 市 。 
我 们 已 经 看 道 ， 即 便 是 在 很 小 的 范围 内 采用 RxJava， 也 会 带 来 一 些 收益 。 按 照 Rx 的 思路 
来 设计 API 并 不 会 影响 整体 的 架构 ， 因 为 随时 都 可 以 回 退 到 BLockingobservabte 和 Java 
集合 。 但 是 最 好 广泛 地 采用 RxJava,， 减少 对 BlockingObservable 和 Java 集合 的 使 用 。 


延迟 分 页 和 连结 
借助 RxJava， 会 有 更 多 方式 来 实现 延迟 分 页 。 如 果 你 思考 一 下 这 个 问题 ， 加 载 分 页 数据 的 
最 简单 方式 就 是 将 所 有 内 容 都 加 载 进来 ， 然 后 按 需 进行 提取 。 这 种 做 法 听 起 来 有 点 傻 ， 但 
是 借助 于 延迟 执行 的 特性 ， 其 实 是 可 行 的 。 首 先 ， 生 成 所 有 可 能 出 现 的 页 面 编 号 ， 然 后 分 
别 加 载 每 页 的 数据 ， 如 下 所 示 。 
Observable<List<Person>> aLLPages = Observable 
.range(0, Integer .MAX_VALUE) 


.map(this::LLstPeopLe) 
.takeWhile(list -> !list.isEmpty()); 


如 果 没 有 RxJava， 上 述 的 代码 会 占用 大 量 的 时 间 和 内 存 ， 基 本 上 相当 于 把 整个 数据 库 加 
载 到 了 内 存 中 。 但 是 ， 因 为 Observable 是 延迟 执行 的 ， 所 以 还 没有 任何 对 数据 库 的 查询 。 
除 此 之 外 ， 如 果 发 现 一 个 空 的 数据 页 ， 就 意味 着 后 续 的 数据 页 也 会 是 空 的 (已 经 到 达 了 
表 的 底部 )。 因 此 ， 我 们 使 用 takewhile()， 而 不 是 filter()。 为 了 将 aLLPages 扁平 化 为 
Observable<Person>， 可 以 使 用 concatMap() (参见 3.1.5 节 )。 








































































































Observable<Person> people = allPpages.concatMap(Observable: :from); 


concatMap() 需要 一 个 从 List<Person> 到 0bservable<Person> 的 转换 ， 每 个 数据 页 都 会 执 
行 这 个 转换 。 作 为 替代 方案 ， 还 可 以 尝试 concatMapIterable()。 它 做 的 是 相同 的 事情 ， 只 
不 过 ， 转 换 要 针对 每 个 上 游 值 返回 一 个 Iterable<Person> (在 这 里 ， 上 游 值 恰好 已 经 是 
Iterable<Person> 了 ) 。 
































Observable<Person> people = allPages.concatMapIterable(page -> page); 


不 管 你 采用 哪 种 方式 ， 所 有 对 Person 对 象 的 转换 都 是 延迟 执行 的 。 只 要 你 限制 想 要 处 
理 的 记录 数量 (比如 people.take(15))，0bservable<Person> 就 会 尽 可 能 地 往 后 推迟 对 
listPeople() 的 调用 。 
































4.5 ”命令 式 并 发 
在 企业 级 应 用 程序 中 ， 显 式 的 并 发 并 不 常见 。 大 多 数 情 况 下 ， 每 个 请 求 都 会 由 单个 线程 处 
理 。 同 一 个 线程 要 完成 如 下 工作 。 


接收 TCP/IP 连接 。 

解析 HTTP 请 求 。 

调用 控制 器 或 Servlet。 

阻塞 对 数据 库 的 调用 。 

处 理 结果 。 

编码 响应 (比如 以 JSON 格式 )。 

将 原始 字 节 推送 至 客户 端 。 
如 果 后 端 要 发 起 多 个 独立 的 请 求 ， 比 如 访问 数据 库 ， 那 么 这 种 分 层 的 模型 会 影响 用 户 的 延 
迟 。 它 们 是 序列 化 执行 的 ， 然 而 可 以 很 容易 地 并 行 处 理 。 除 此 之 外 ， 扩 展 性 也 会 受到 影 
响 。 例 如 ， 在 Tomcat 的 执行 器 (executor) 中 ， 默 认 有 200 个 负责 处 理 请 求 的 线程 ， 这 意 
味 着 处 理 的 并 发 连接 不 能 超过 200 个 。 如 果 流 量 突然 暴 增 ， 传 入 的 连接 将 会 排队 ， 服 务 器 
就 会 出 现 更 高 的 延迟 。 但 是 ， 这 种 情况 不 会 持续 下 去 ，Tomcat 最 终 会 开始 拒绝 传 入 的 流 
量 。 第 5 章 将 用 大 量 的 篇 幅 (参见 5.1.2 节 ) 介绍 如 何 处 理 这 个 相当 鸠 座 的 缺点 。 就 目前 
来 说 ， 我 们 还 是 继续 关 广 传 统 的 架构 。 在 一 个 线程 中 执行 请 求 处 理 的 各 个 步骤 也 有 一 些 益 
处 ， 比 如 能 够 提升 缓存 的 本 地 化 以 及 减少 同步 的 损耗 。' 令 人 遗憾 的 是 ， 在 典型 的 应 用 程序 
中 ， 因 为 整体 的 延迟 是 每 层 延 迟 的 总 和 ， 所 以 一 个 有 故障 的 组 件 可 能 会 对 整体 的 延迟 产生 
负面 影响 。? 此外， 有 时 许多 步骤 是 相互 独立 的 ， 可 以 并 发 执行 。 例 如 ， 调 用 多 个 外 部 API 
或 执行 多 个 独立 的 SQL 查询 。 
JDK 对 并 发 提供 了 和 良好 的 支持 ， 尤 其 是 Java 5 提供 的 Executorservice 和 Java 8 提供 的 
CompletableFuture。 但 是 ， 它 们 并 没有 得 到 应 有 的 广泛 使 用 。 例 如 ， 以 下 是 一 个 没有 任何 
并 发 功能 的 程序 。 

Flight lookupFlight(String flightNo) { 
a 































































































} 


Passenger findPassenger(Long id) { 
//... 
} 


Ticket bookTicket(Flight flight, Passenger passenger) { 
/ss 
} 


SmtpResponse sendEmail(Ticket ticket) { 
Lass 
} 
























































注 1: 事实 上 ，RxJava 凭借 线程 亲 和 性 ， 试 图 停留 在 事件 循环 模型 中 的 同一 线程 上 ， 以 利用 这 一 点 。 
注 2: 参见 8.2.3 节 。 
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客户 端 代码 如 下 所 示 。 


Flight flight = lookupFlight("LOT 783"); 
Passenger passenger = findpassenger(42); 
Ticket ticket = bookTicket(flight, passenger); 
sendEmail(ticket); 


同样 ， 这 是 非常 典型 的 阻塞 式 代 码 ， 与 众多 应 用 程序 中 的 代码 都 很 类 似 。 但 是 ， 如 果 从 延 
迟 的 角度 来 看 ， 上 述 的 代码 片段 可 以 分 为 4 个 步骤 。 前 两 个 步骤 相互 独立 ， 只 有 第 三 个 
步骤 (bookTicket()) 需要 LookupFLight() 和 findPassenger() 的 返回 值 。 这 里 显然 有 机 
会 利用 并 发 的 优势 ， 但 是 ， 开 发 人 员 很 少 采 用 这 种 方式 ， 因 为 这 需要 比较 复杂 的 线程 池 、 
Future 以 及 回调 。 但 是 ， 如 果 API 已 经 兼容 Rx 了 ， 你 可 以 简单 地 将 遗留 的 阻塞 式 代码 包 
装 到 0bservable 中 ， 就 像 本 章 开篇 那样 。 

Observable<Flight> rxLookupFlight(String flightNo) { 


return Observable.defer(() -> 
Observable.just(lookupFlight(flightNo))); 











T= 

















} 


Observable<Passenger> rxFindPassenger(Long id) { 
return Observable.defer(() -> 
Observable.just(findpassenger (id))); 
} 


从 语义 上 讲 ，rx- 方法 其 实 以 相同 的 方式 完成 了 相同 的 任务 ， 换 言 之 ， 它 们 默认 都 是 阻塞 
的 。 从 客户 端的 角度 看 ， 除 了 API 更 加 元 长 之 外 ， 我 们 其 实 没 有 得 到 任何 好 处 。 
Observable<Flight> flight = rxLookupFlight("LOT 783"); 
Observable<Passenger> passenger = rxFindPassenger(42); 
Observable<Ticket> ticket = 


flight.zipwith(passenger, (f, p) -> bookTicket(f, p)); 
ticket.subscribe(this::sendEmail); 


无 论 是 传统 的 阻塞 程序 ， 还 是 使 用 observabte 的 程序 ， 它 们 的 运行 方式 完全 相同 。 上 
述 代码 片段 默认 是 延迟 执行 的 ， 但 是 操作 的 顺序 依然 非常 重要 。 首 先 ， 我们 创建 
Observable<Flight>， 上 默认 情况 下 ， 此 时 并 不 会 执行 任何 操作 。 在 有 人 明确 要 求 一 个 
Flight 之 前 ，0bservablte 只 是 一 个 延迟 执行 的 占 位 符 。 我 们 已 经 介绍 过 ， 这 是 cold 类 型 的 
observable 非常 有 价值 的 一 个 特性 。0bservable<Passenger> 的 情况 完全 相同 。 现 在 我 们 有 
了 Flight 和 Passenger 类 型 的 两 个 占 位 符 ， 但 是 还 没有 产生 任何 的 副作用 。 此 时 ， 并 设 有 
执行 任何 的 数据 库 查询 或 Web 服务 调用 。 如 果 从 这 里 决定 停止 处 理 ， 甚 实 并 没有 执行 任何 
多 余 的 工作 。 


为 了 处 理 bookTicket()， 我 们 需要 具体 的 Flight 和 Passenger 实例 。 最 先 想到 的 做 法 就 是 
使 用 toBlocking() 操作 符 阻塞 这 两 个 0Observable。 但 是 ， 我 们 应 该 尽 可 能 地 人 避免 阻塞 ， 从 
而 减少 资源 (尤其 是 内 存 ) 的 消耗 ， 支 撑 更 高 的 并 发 性 。 男 一 个 比较 精 糕 的 解决 方案 就 是 
通过 .subscribe() 方法 订阅 flight 和 passenger 0bservable， 然 后 以 某 种 方式 等 待 它们 的 
回调 完成 。 如 果 0bservable 是 阻塞 的 ， 实 现 起 来 非常 简单 ， 但 是 如 果 回 调 是 异步 的 ， 你 就 
需要 同步 一 些 全 局 的 状态 ， 以 等 待 这 两 者 完成 ， 这 种 方式 很 快 就 会 变 成 一 个 垩 梦 。 同 时 ， 
内 嵌 的 subscribe() 也 不 符合 习惯 的 用 法 ,通常 情况 下 ， 你 想 要 对 一 个 信息 流 (用 例 ) 只 











































































































进行 一 次 订阅 。 在 JavaScript 中 ， 回 调 机 制 能 够 比较 好 地 运行 的 原因 在 于 它 只 有 一 个 线程 。 
同时 订阅 多 个 Observable 的 习惯 用 法 是 zip 和 zipwith。 你 可 能 认为 zip 是 将 两 个 独立 数 
据 流 中 的 元 素 两 两 连接 起 来 的 一 种 方式 。 但 是 更 常见 的 场景 是 ，zip 仅仅 用 于 将 两 个 单条 
目的 Observable 连接 起 来 。ob1.zip(ob2).subscribel(...) 本 质 上 意味 着 obl 和 ob2 都 完成 
(二 者 各 自发 布 完 一 个 事件 ) 的 时 候 ， 它 才 会 接收 到 一 个 事件 。 所 以 ， 当 你 看 到 zip 的 时 
候 ， 很 可 能 是 有 人 只 针对 两 个 或 更 多 的 0bservable 执行 了 一 个 连接 (join) 步骤 ， 这 两 个 
Observable 会 有 分 又 (fork) 执行 路 径 。zitp 是 异步 等 待 两 个 或 多 个 值 的 一 种 方式 ， 不 管 哪 
个 值 最 后 出 现 。 


我 们 再 回 到 flight.zipwith(passenger，this::bookTicket) (使 用 了 方法 引用 来 赫 代 显 
式 lambda 表达 式 ， 从 而 更 加 简短 )。 这 里 我 保留 了 所 有 的 类 型 信息 ， 而 不 是 将 表达 式 流 
畅 地 连接 在 一 起 ， 这 样 做 的 原因 是 想 让 你 关注 返回 的 类 型 。 在 flight 和 passenger 就 
绪 之 后 ，flight.zipwith(passenger，...) 并 不 会 简单 地 调用 回调 ， 它 会 返回 一 个 新 的 
0bservable， 你 可 能 会 立即 意识 到 这 是 一 个 延迟 的 数据 占 位 符 。 到 目前 为 止 ， 我 们 没有 局 
动 任何 的 计算 ， 只 是 将 几 个 数据 结构 包装 在 了 一 起 ， 没 有 触发 任何 的 行为 。 只 要 没有 人 订 
阅 Observable<Ticket>，RxJava 就 不 会 运行 任何 后 端 代 码 。 而 订阅 是 在 最 后 一 个 语句 中 完 
成 的 : ticket.subscribe() 方法 会 显 式 请 求 Ticket。 

应 该 在 何 处 订阅 ? 
在 领域 代码 中 ， 要 关注 subscribe() 位 于 何 处 。 通 常 ， 你 的 业务 逻辑 只 是 一 
直 组 合 Observable， 并 将 它们 返回 给 某 个 框架 或 者 脚手架 层 。 实 际 的 订阅 是 
由 Web 框架 或 某 些 胶水 代码 在 幕后 完成 的 。 自 行 调 用 subscribe() 也 算 不 上 
糟糕 的 实践 ， 但 是 将 订阅 推迟 得 越 远 越 好 。 

























































































为 了 理解 执行 的 流程 ， 从 下 往 上 观察 是 一 种 非常 有 帮助 的 方法 。 我 们 订阅 了 ticket， 因 
此 RxJava 必须 透明 地 订阅 flight 和 passenger。 此 时 ， 真 正 的 业务 逻辑 才 会 执行 。 因 为 
两 个 0bservable 都 是 cold 类 型 的 ， 并 且 没 有 涉及 并 发 ， 所 以 对 flight 的 订阅 会 在 调用 线 
程 中 触发 LookupFLight() 阻塞 方法 。 当 LookupFLight() 完成 的 时 候 ，RxJava 就 可 以 订阅 
passenger 了 。 此 时 ， 它 已 经 通过 同步 的 flight 接收 到 Flight 实例 。rxFindPassenger() 
会 以 阻塞 的 方式 调用 findPassenger() 并 接收 一 个 Passenger 。 经 过 这 个 连接 点 之 后 ， 数 据 
会 往 下 游 流 动 。Flight 和 Passenger 实例 通过 提供 的 lambda 表达 式 (bookTicket) 被 结合 
起 来 ， 传 递 给 ticket.subscribe()。 


听 上 去 这 里 有 不 少 工作 要 做 ， 运 行 方式 在 本 质 上 和 开始 的 阻塞 式 代 码 并 没有 区 别 。 但 
是 ， 现 在 我 们 不 需要 修改 任何 逻辑 就 能 声明 式 地 应 用 并 发 了 。 如 果 业 务 方法 返回 
Future<Flight> (或 者 CompLetabLeFuture<FLight>， 没 有 本 质 区 别 ) ， 其 实 系 统 已 经 为 我 们 
做 出 了 两 个 决策 。 


底层 对 LookupFLight() 的 调用 已 经 开始 ， 这 里 没有 任何 延迟 执行 的 空间 。 我 们 不 会 在 
这 个 方法 上 阻塞, 但 是 工作 已 经 启动 。 

我 们 对 并 发 没有 任何 控制 权 。 方 法 的 具体 实现 决定 了 Future 任务 是 在 线程 池 调 用 ， 还 
是 为 每 个 请 求 建立 一 个 新 的 线程 。 
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RxJava 给 了 用 户 更 多 的 控制 权 。0bservable<Flight> 在 实现 的 时 候 没 有 将 并 发 考虑 进去 ， 
但 我 们 在 后 续 的 操作 中 依然 可 以 使 用 并 发 。 现 实 中 的 0bservable 一 般 都 已 经 是 异步 的 了 ， 
但 是 在 个 别 情况 下 ， 还 是 需要 为 已 有 的 Observable 添加 并 发 功能 。 在 遇 到 同步 0bservable 
时 ， 可 以 自由 决定 线程 机 制 的 是 API 的 消费 者 ， 而 不 是 API 的 实现 者 。 上 述 功 能 都 是 通过 
subscribe0n() 操作 符 实现 的 ， 如 下 所 示 。 
Observable<Flight> flight = 
rxLookupFlight("LOT 783").subscribeOn(Schedulers.io()); 


Observable<Passenger> passenger = 
rxFindPassenger(42).subscribeOn(Schedulers.io()); 


我 们 可 以 在 订阅 之 前 的 任何 地 方 插入 subscribeon() 操作 符 ， 并 提供 一 个 所 谓 的 scheduler 实 
例 。 本 例 中 使 用 了 schedulers.io() 工厂 方法 ， 不 过 也 可 以 使 用 自 定义 的 ExecutorService 
并 通过 Scheduler 进行 简单 包装 。 订 阅 发 生 时 ， 传 递 给 0bservable.create() 的 lambda 表 
达 式 会 在 提供 的 Scheduler 中 执行 ， 而 不 是 在 客户 端 线程 中 。4.9.1 证 将 会 深度 研究 调度 
器 ， 目 前 可 以 将 Scheduler 视 为 一 个 线程 池 。 


那么 Scheduler 如 何 改变 程序 运行 时 的 行为 ? zip() 操作 符 能 够 订阅 两 个 或 更 多 的 0bservable， 
并 等 待 形成 一 个 配对 (或 元 组 ) 元 素 。 订 阅 异步 发 生 时 ， 所 有 上 游 的 Observable 都 可 以 并 
发 地 调用 其 阻塞 式 代 码 。 如 果 你 在 运行 程序 时 调用 ticket.subscribe()，lookupFlight() 
和 findPassenger() 会 立即 并 发 执行 。 这 两 个 0bservable 中 较 慢 的 一 个 发 布 值 之 后 ， 
bookTicket() 将 会 立即 执行 。 


既然 提 到 了 程序 执行 的 快慢 ， 如 果 给 定 的 0bservable 在 给 定时 间 内 未 发 布 任何 值 ， 你 还 可 
以 声明 式 地 设置 一 个 超时 ， 如 下 所 示 。 
rxLookupFlight("LOT 783") 


.SubscribeOn(Schedulers.io()) 
.timeout(100, TimeUnit.MILLISECONDS) 


和 以 前 一 样 ， 如 果 出 现 错误 ， 这 些 错误 会 向 下 游 传递 ， 而 不 是 随意 抛 出 。 所 以 ， 如 
LookupFLight() 方法 的 耗 时 超过 了 100 毫秒 ， 最 终 将 会 形成 TimeoutException， 而 不 会 给 
下 游 每 个 订阅 者 都 发 布 某 个 值 。 我 们 将 在 7.1.3 节 中 详细 介绍 timeout() 操作 符 。 


假设 API 已 经 是 Rx 驱动 的 ， 我 们 不 用 花费 太 大 的 力气 就 能 让 两 个 方法 并 发 执行 。 但 是 
bookTicket() 依然 有 点 美中不足 ， 它 返回 的 是 Ticket， 训 无 疑问 是 阻塞 式 的 。 尽 管 订 票 
的 执行 过 程 可 能 会 非常 迅速 ， 但 是 将 其 按照 Rx 的 方式 进行 声明 也 是 值得 的 ， 这 样 会 让 
API 更 易于 演化 。 演 化 可 能 意味 着 添加 对 并 发 的 支持 ， 或 者 用 于 完全 非 阻塞 的 环境 ( 参 
见 第 5 章 )。 将 非 阻塞 API 转换 为 阻塞 API 非常 容易 ， 只 需 调用 toBlocking()。 而 反方 向 
的 转换 通常 更 具 挑 战 性 ， 需 要 很 多 额外 的 资源 。 同 时 ， 对 于 像 rxBookTicket() 这 样 的 方 
法 ， 很 难 预测 其 演化 方式 ， 如 果 它 们 接触 网 络 或 文件 系统 ， 其 至 数据 库 ， 那 么 就 值得 使 用 
Observable 进行 包装 ， 以 便 在 类 型 级 别 上 就 表明 可 能 会 出 现 延 迟 。 


Observable<Ticket> rxBookTicket(Flight flight, Passenger passenger) { 
AN 
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} 
但 是 ， 现 在 zipwith() 返回 的 是 一 个 看 上 去 很 诡异 的 0bservabLe<0bservabLe<Ticket>>， 





并 且 无 法 再 编译 代码 。 根 据 经 验 ， 每 当 你 看 到 双重 包装 的 类 型 (比如 0ptionaL<0ptional 
<.….>>)， 就 意味 着 在 某 些 地 方 缺失 了 对 flatMap() 的 调用 。 这 里 同样 如 此 。zipwith() 会 
接收 成 对 (或 更 通用 的 元 组 ) 出 现 的 事件 ， 以 这 些 事件 为 参数 应 用 某 个 函数 ， 然 后 将 结果 
原样 放 到 下 游 0bservable 中 。 这 就 是 为 什么 我 们 最 初 看 到 的 是 0bservable<Ticket>， 而 现 
在 看 到 的 是 Observable<0bservable<Ticket>>， Observable<Ticket> 是 我 们 提供 的 
图 数 的 执行 结果 。 解 决 这 个 问题 的 方式 有 两 种 ， 第 一 种 方式 就 是 使 用 zipwith 返回 一 个 中 
间 配 对 类 型 ， 如 下 所 示 。 


import org.apache.commons.lang3.tuple.Pair; 





























Observable<Ticket> ticket = flight 
.ZipWith(passenger, (Flight f, Passenger p) -> Pair.of(f, p)) 
.flatMap(pair -> rxBookTicket(pair.getLeft(), pair.getRight())); 


如 果 使 用 第 三 方 的 Pair 类 型 不 足以 遮蔽 流 ， 那 么 方法 引用 也 可 以 完成 这 项 功能 
Pair::of。 但 是 在 这 里 ， 相 对 于 节省 几 次 键盘 输入 ， 让 类 型 信息 可 见 是 更 有 价值 的 。 毕 
竞 ， 阅 读 代码 的 次 数 要 比 编写 代码 的 次 数 多 一 些 。 替 代 中 间 配 对 类 型 的 一 种 方案 就 是 使 用 
flatMap， 并 为 其 传递 一 个 恒等式 函数 。 

Observable<Ticket> ticket = flight 


.ZipWith(passenger, this::rxBookTicket) 
.flatMap(obs -> obs); 


这 个 obs -> obs lambda 表达 式 看 起 来 什么 事情 都 没有 做 ， 至 少将 其 应 用 到 map() 操作 符 

中 的 时 候 是 这 样 。 但 是 ，flatMap() 会 将 一 个 函数 应 用 到 0bservable 中 的 每 个 值 ， 所 以 
场景 中 的 函数 会 接收 0bservable<Ticket> 作为 参数 。 随 后 ， 结 果 并 未 直接 放 到 最 终 

形成 的 流 中 ， 这 和 使 用 map() 是 一 样 的 。 相 反 ， 返 回 值 (类 型 为 Oobservable<T>) 会 被 “局 

平 化 ”。 这 样 形成 的 就 是 Observable<T>， 而 不 是 Observable<0bservable<T>>。 使 用 调度 器 

进行 处 理 的 时 候 ，flatMap() 操作 符 会 变 得 更 加 强大 。 你 也 许 认 为 flatMap() 只 是 用 来 解决 

Observable<0bservable<...>> 从 套 问题 的 一 个 语法 技巧 ， 其 实 它 还 能 提供 更 加 基础 的 功能 。 

0bservabtLe.subscribeon() 的 用 例 

我 们 难免 会 认为 subscribeon() 是 在 RxJava 中 实现 并 发 的 恰当 工具 。 这 

个 操作 符 的 确 能 够 实现 这 一 点 ， 但 尽量 还 是 不 要 使 用 它 (以 及 后 文 描 述 的 

observe0n())。 在 现实 中 ，0bservable 来 源 于 异步 源 ， 所 以 根本 就 没有 必要 

进行 自 定义 的 调度 。 本 章 使 用 subscribe0n() 只 是 为 了 展现 如 何 升级 已 有 的 

应 用 程序 ， 从 而 有 选择 性 地 使 用 反应 式 原则 。 但 是 ， 在 实践 中 ，Scheduler 

和 subscribeon() 应 该 是 最 后 的 “武器 *"， 所 以 它们 并 不 那么 常见 。 


















































4.6 flatMap() 作 为 异步 链接 操作 符 


在 样 例 应 用 程序 中 ， 必 须要 通过 电子 邮件 发 送 一 个 Ticket 列表 。 在 这 个 过 程 中 ， 我 们 必须 
要 注意 以 下 3 点 。 


(1) 这 个 列表 可 能 会 很 长 。 
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(2) 发 送 一 封 邮 件 可 能 会 耗费 几 毫 秒 ， 甚 至 几 秒 的 时 间 。 
(G3) 在 出 现 故障 时 ， 应 用 程序 必须 保持 平稳 地 运行 ， 但 是 最 后 要 报告 哪些 ticket 没有 成 功 
投递 。 
最 后 一 项 需求 迅速 排除 了 简单 的 tickets.forEach(this::sendEmail) 方式 ， 因 为 这 种 方式 
会 立即 抛 出 异常 ， 并 且 不 会 继续 投递 ticket。 实 际 上 ， 异 常 机 制 是 类 型 系统 中 的 一 个 非常 
粳 糕 的 后 门 ， 就 像 回 调 一 样 ， 想 要 以 更 加 健壮 的 方式 对 它们 进行 管理 时 ， 它 们 都 不 是 非常 
友好 。 这 就 是 RxJava 将 它们 显 式 地 建 模 为 特殊 类 型 通知 的 原因 ， 本 书 会 在 后 面 介绍 这 些 
内 容 。 回 到 错误 处 理 相 关 的 需求 ， 代 码 大 致 如 下 所 示 。 
List<Ticket> failures = new ArrayList<>(); 


for(Ticket ticket: tickets) { 
try { 
sendEmail(ticket); 
} catch (Exception e) { 
log.warn("Failed to send {}", ticket, e); 
failures.add(ticket); 





























be! 

















} 
但 是 ， 前 面 两 个 需求 或 行为 指南 尚未 得 到 解决 。 我 们 没有 理由 在 一 个 线程 中 序列 化 地 发 送 
电子 邮件 。 按 照 传 统 的 方式 ， 我 们 可 以 使 用 ExecutorService pool， 将 每 封 电子 邮件 提交 
为 一 个 独立 的 任务 。 
List<Pair<Ticket, Future<SmtpResponse>>> tasks = tickets 
.Stream() 


.map(ticket -> Pair.of(ticket, sendEmailAsync(ticket))) 
.collect(toList()); 
































List<Ticket> failures = tasks.stream() 
.flatMap(pair -> { 
try { 
Future<SmtpResponse> future = pair.getRight(); 
future.get(1, TimeUnit.SECONDS); 
return Stream.empty(); 
} catch (Exception e) { 
Ticket ticket = pair.getLeft(); 
log.warn("Failed to send {}", ticket, e); 
return Stream.of(ticket); 
} 
}) 
.Collect(toList()); 


private Future<SmtpResponse> sendEmailAsync(Ticket ticket) { 
return pool.submit(() -> sendEmail(ticket)); 


} 
所 有 使 用 Java 的 开发 人 员 对 这 些 代码 应 该 已 经 非常 熟悉 了 。 但 是 ， 它 看 上 去 非常 元 长 和 
复杂 。 首 先 ， 需 要 遍历 tickets， 并 将 它们 提交 到 一 个 线程 池 中 。 准 确 地 说 ， 我 们 调用 
sendEmailAsync() 辅助 方法 ， 将 对 sendEmail() 的 调用 提交 到 一 个 线程 地 中 ， 执 行 过 程 会 























包装 到 一 个 Callable<SmtpResponse> 中 。 更 准确 地 说 ，Callable 的 实例 被 先 放 到 线程 池 前 
面 的 一 个 无 界 (默认 情况 下 ) 队列 中 。 如 果 任 务 提 交 的 速度 太 快 ， 它 们 将 无 法 及 时 得 到 处 
理 。 这 里 缺乏 一 种 减缓 提交 速度 的 机 制 ， 这 也 是 反应 式 流 和 回 压 致力 于 解决 的 问题 (参见 
6.2 节 )。 


因为 之 后 我 们 需要 一 个 Ticket 实例 以 防 出 现 故障 ， 所 以 必须 跟踪 哪个 Future 负责 哪个 
Ticket， 这 里 再 次 以 Pair 来 表示 。 在 实际 的 生产 代码 中 ， 你 应 该 考虑 采用 更 有 意义 的 专门 
的 容器 ， 比 如 TicketAsyncTask 值 对 象 。 我 们 将 所 有 这 样 的 配对 信息 收集 起 来 ， 并 在 下 一 轮 
进行 处 理 。 此 时 ， 线 程 地 中 已 经 并 发 运行 多 个 sendEmail() 调用 了 ， 这 正 是 我 们 要 达到 的 目 
标 。 第 二 个 循环 遍历 所 有 的 Future， 并 试图 通过 阻塞 (get()) 和 等 待 完成 的 方式 来 解除 对 
它们 的 引用 。 如 果 get() 成 功 返回 ， 将 会 跳 过 这 个 Ticket。 但 是 ， 如 果 出 现 异 常 ， 将 会 返回 
与 该 任务 关联 的 Ticket 实例 ， 这 样 就 能 知道 它 失 败 了 ， 稍 后 再 报告 它 。Stream.flatMap() 
允许 返回 零 个 或 一 个 元 素 (实际 上 可 以 是 任意 数量 )， 而 Stream.map() 通常 需要 一 个 元 素 。 


你 可 能 想 问 ， 为 何 需 要 两 个 循环 而 不 是 如 下 的 一 个 循环 呢 ? 
// 警 告 : 尽管 使 用 了 线程 地 ， 但 代码 依然 是 序列 化 执行 的 


List<Ticket> failures = tickets 
.Stream() 
.map(ticket -> Pair.of(ticket, sendEmailAsync(ticket))) 
.flatMap(pair -> { 
es 
























































}) 
.COLLect(toList() ); 


如 果 你 不 理解 Java 8 的 Strean 是 如 何 运行 的 ， 就 很 难 发 现 这 里 有 一 个 非常 有 意思 的 bug。 
因为 流 与 Observable 类 似 ， 它 们 都 是 延迟 执行 的 ， 所 以 只 有 在 请 求 终端 操作 (terminal operation) 
的 时 候 〈 例 如 coLLect(toList())) ， 才 会 针对 底层 集合 中 的 每 个 元 素 依 次 执行 操作 。 这 意 
味 着 启动 后 台 任 务 的 map() 操作 并 没有 针对 所 有 ticket 立即 执行 ， 而 是 每 次 只 执行 一 个 元 
素 ， 交 替 使 用 flatMap()。 除 此 之 外 ， 我 们 实际 上 启动 了 一 个 Future， 阻 塞 等 待 ， 然 后 局 
动 第 二 个 Future， 阻 塞 等 待 ， 以 此 类 推 。 这 里 需要 一 个 中 间 的 集合 对 象 是 为 了 强制 执行 ， 
而 不 是 为 了 代码 的 清晰 和 可 读 性 。 毕 帝 ，List<Pair<Ticket，Future<SmtpResponse>>> 类 型 
已 经 谈 不 上 什么 可 读 性 了 。 


这 里 涉及 很 多 工作 ， 并 且 出 现 错误 的 可 能 性 非常 高 ， 所 以 开发 人 员 在 日 常 工作 中 不 愿意 使 
用 并 发 代码 也 就 不 足 为 奇 了 。 如 果 有 一 个 异步 任务 的 池 ， 并 且 我 们 想 在 任务 完成 的 时 候 
对 它们 进行 处 理 ， 那 么 可 以 使 用 JDK 中 不 太 为 人 所 知 的 ExecutorCompletionService。 男 
外 ，Java 8 引入 了 CompletableFuture (参见 5.4 节 )， 它 是 完全 反应 式 和 非 阻塞 的 。 那 么 ， 
RxJava 在 这 个 场景 中 能 够 发 挥 什么 作用 ? 首先， 假设 发 送 电 子 邮 件 的 API 已 经 被 更 新 为 使 
用 RxJava， 如 下 所 示 。 


import static rx.Observable.fromCallable; 



































Observable<SmtpResponse> rxSendEmail(Ticket ticket) { 
// 较 为 少见 的 同步 Observable 
return fromCallable(() -> sendEmail()) 

} 
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这 里 还 没有 涉及 并 发 ， 它 只 是 将 sendEmail() 包装 进 了 一 个 0bservabte 中 。 这 种 0bservable 
并 不 常见 。 正 常情 况 下 ， 我 们 会 在 实现 中 使 用 subscribe0n()， 以 便于 0bservable 默认 采 
取 异 步 的 运行 方式 。 在 这 里 ， 可 以 像 前 面 一 样 遍历 所 有 的 tickets。 


List<Ticket> failures = Observable.from(tickets) 
.flatMap(ticket -> 
rxSendEmail(ticket) 

.flatMap(response -> Observable.<Ticket>empty()) 
.doOnError(e -> log.warn("Failed to send {}", ticket, e)) 
.ONErrorReturn(err -> ticket)) 

.toList() 

.toBlocking() 

.single(); 








Observable.ignoreElements() 


在 以 上 的 样 例 中 ， 很 容易 看 到 内 层 的 flatMap() 忽略 了 response 并 返回 了 
一 个 空 的 流 。 在 这 样 的 场景 中 ，flatMap() 就 有 点 大 材 小 用 了 ， 更 有 效 的 方 
式 是 ignoreElements()。ignoreElements() 会 忽略 上 游 发 布 的 值 ， 只 转发 
onCompleted() 或 onError() 通知 。 因 为 我 们 忽略 实际 的 响应 ， 只 处 理 错 误 ， 
所 以 这 里 的 ignoreElements() 能 够 运行 得 非常 好 。 


















































我 们 感 兴趣 的 内 容 都 在 外 层 flatMap() 中 。 如 果 只 是 使 用 flatMap(this::rxSendEmail)， 
代码 也 可 以 运行 ， 只 不 过 rxSendEmail 引发 的 任何 故障 都 会 终结 整个 流 。 但 是 ， 我 们 想 要 
“捕获 ”所 有 发 布 出 来 的 错误 ， 将 其 收集 起 来 供 后 续 使 用 。 我 们 使 用 了 与 Stream.flatMap() 
类 似 的 技巧 : 如 果 response 能 够 成 功 发 布 ， 就 将 其 转换 为 一 个 空 的 0bservable。 它 的 基本 
含义 就 是 丢弃 成 功 的 ticket。 但 是 ， 如 果 遇 到 故障 ， 样 例会 返回 引发 故障 的 ticket。 额 外 
的 doonError() 回调 允许 将 异常 以 日 志 的 形式 记录 下 来 。 当 然 ， 也 可 以 将 日 志 记 录 添 加 到 
onErrorReturn() 操作 符 中 ,但 是 我 们 发 现 这 种 关注 点 分 离 的 方式 更 符合 函数 式 的 风格 。 


为 了 与 之 前 的 实现 保持 兼容 ， 我 们 将 0bservable 转换 为 0bservabLe<List<Ticket>>、BLock 
ingObservable<List<Ticket>>、toBlocking(), 最 终 得 到 List<Ticket> (single())。 有 意思 
的 是 ，BLocking0bservable 依然 是 延迟 执行 的 。toBlocking() 操作 符 本 身 并 不 会 在 订阅 底 
层 流 的 时 个 就 强制 执行 ， 它 甚至 不 会 阻塞 。 订 阅 以 及 后 续 的 进 代 和 发 送 电子 邮件 ， 会 延迟 
到 调用 single() 的 时 候 才 执行 。 


需要 注意 ， 如 果 将 外 层 的 flatMap() 替换 为 concatMap() (参见 3.1.5 节 和 3.4.1 节 )， 我 们 
将 会 遇 到 与 前 文 提 及 的 JDK 中 的 Stream 类 似 的 bug。flatMap (或 merge) 会 立即 订阅 所 有 
的 内 部 流 。 与 之 相反 ，concatMap (或 concat) 则 会 依次 订阅 每 个 内 部 Observable。 并 且 只 
要 没有 人 真正 订阅 Observable， 它 就 不 会 开展 任何 工作 。 


到 目前 为 止 ， 一 个 带 有 try-catch 的 for 循环 被 奉 换 成 了 更 难 阅读 、 更 复杂 的 0bservable。 
但 是 ， 为 了 将 序列 化 代码 转换 为 多 线程 计算 ， 我 们 只 需要 再 加 一 个 操作 符 ， 如 下 所 示 。 


Observable 
.from(tickets) 
.flatMap(ticket -> 
rxSendEmail(ticket) 
.TignoreElements() 











.do0nError(e -> log.warn("Failed to send {}", ticket, e)) 
.ONErrorReturn(err -> ticket) 
.SubscribeOn(Schedulers.io())) 


它 没 有 太 多 的 侵入 性 ， 你 其 至 可 能 很 难 发 现 它 的 存在 。 额 外 的 subscribe0n() 操作 符 会 
让 每 个 单独 的 rxsendMail() 都 在 一 个 特定 的 Scheduler (本 例 中 是 io()) 中 执行 ， 这 是 
RxJava 的 优势 之 一 。 在 线程 方面 ， 它 没有 预 设立 场 ， 默 认同 步 执 行 ， 但 是 它 能 够 实现 无 颖 
其 至 透明 的 多 线程 功能 。 当 然 ， 这 并 不 意味 着 你 可 以 在 任意 位 置 安全 地 注入 调度 器 。 只 不 
过 ， 它 的 API 更 加 简洁 ， 抽 象 层级 也 更 高 。4.9 节 将 更 详细 地 探讨 调度 器 。 现 在 ， 你 只 需 
要 记 住 0bservable 默认 是 同步 的 。 但 是 ， 我 们 可 以 很 轻松 地 改变 这 种 行为 ， 将 并 发 功能 
用 到 往常 我 们 认为 不 可 能 出 现 的 地 方 。 这 对 于 现存 的 遗留 应 用 程序 很 有 价值 ， 借 助 这 种 功 
能 ， 可 以 轻松 地 对 其 进行 优化 。 


如 果 你 从 头 开始 实现 observable， 将 它们 封装 起 来 ， 并 默认 实现 异步 化 更 符合 习惯 用 法 。 
这 就 意味 着 要 将 subscribeon() 直接 放 到 rxsendEmail() 中 ， 而 不 是 放 到 外 部 。 否 则 ， 你 可 
能 就 要 使 用 额外 的 一 层 调度 器 来 包装 已 经 异步 化 的 流 了 。 当 然 ， 如 果 0bservable 背后 的 生 
产 者 已 经 是 异步 化 的 ， 那 么 流 就 不 用 绑 定 任何 的 特定 线程 。 除 此 之 外 ， 应 该 尽 可 能 推迟 对 
Observable 的 订阅 ， 一 般 这 会 发 生 在 外 部 世界 的 Web 框架 附近 。 这 会 大 大 改变 你 的 思维 方 
式 ， 因 为 整个 业务 逻辑 都 是 延迟 执行 的 ， 直 到 有 人 真正 想 要 看 到 结果 的 时 候 才 会 运行 。” 


4.7 ”使 用 Stream 代 蔡 回 调 


传统 的 API 大 多 数 情况 下 是 阻塞 的 ， 这 意味 着 它们 会 强迫 你 同步 等 竺 结果。 这 种 方式 也 能 
运行 得 非常 好 ， 至 少 在 你 使 用 RxJava 之 前 。 但 是 ， 如 果 数 据 需 要 从 API 的 生产 者 推送 到 
消费 者 ， 阻 塞 式 的 API 就 特别 容易 出 现 问题 ， 而 这 正 是 RxJava 能 够 发 挥 作用 的 地 方 。 这 
样 的 例子 数不胜数 ，API 的 设计 师 也 采用 了 各 种 各 样 的 方式 。 我 们 通常 需要 提供 某 种 形式 
的 回调 供 API 调用 ， 它 们 经 常 被 称 为 事件 监听 器 (event listener)。 最 常见 的 场景 之 一 就 是 
Java 消息 服务 (Java Message Service，JMS)。 消 费 JMS 一 般 需 要 实现 一 个 类 ， 每 次 有 消 
息 传 入， 应 用 程序 的 服务 器 或 容器 就 会 得 到 通知 。 我 们 可 以 将 这 种 相对 简单 的 监听 器 替换 
为 可 组 合 的 Observable， 后 者 会 更 加 健壮 和 灵活 。 传 统 的 监听 器 看 上 去 就 像 下 面 这 个 类 ， 
这 里 使 用 了 Spring 框架 中 的 JMS 支持 ， 但 是 解决 方案 与 具体 技术 无 关 。 


@Component 
class JmsConsumer { 




































































































































































@JmsListener(destination = "orders") 

public void newOrder(Message message) { 
J/ 

} 


} 
JMS 消息 到 达 的 时 候 ，JmsConsumer 类 必须 要 决定 该 如 何 对 它 进行 处 理 。 一 般 在 消息 消费 
者 里 面 会 调用 一 些 业务 逻辑 。 新 的 组 件 想 要 接收 这 样 的 消息 通知 时 ， 它 必须 适当 地 修改 
JmsConsumer。 与 之 不 同 的 是 ，0bservabLe<Message> 可 以 被 任何 人 订阅 。 除 此 之 外 ，RxJava 























注 3: 对 比 Haskell 的 延迟 评估 表达 式 。 
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操作 符 是 完全 通用 的 ， 可 以 进行 映射 、 过 滤 和 组 合 。 使 用 Subject 是 将 基于 推送 、 回 调 的 
API 转换 为 observable 的 最 简单 的 方式 。 每 次 有 新 的 JMS 消息 需要 投递 ， 我 们 就 将 消息 
推送 给 一 个 Publishsubject。 从 外 部 看 ， 它 与 一 个 普通 的 hot 类 型 的 0bservablte 非常 相似 。 





private final PublishSubject<Message> subject = PublishSubject.create(); 


@JmsListener(destination = "orders", concurrency="1") 
public void newOrder(Message msg) { 
subject.onNext(msg); 


} 


Observable<Message> observe() { 
return subject; 


} 


需要 记 住 的 是 ，0bservable<Message> 是 hot 类 型 的 ， 它 们 一 旦 被 消费 就 会 开始 发 布 JMS 消 
息 。 如 果 此 时 没有 人 订阅 它 ， 消 息 就 会 丢失 。ReptLaySubject 可 以 作为 替代 方案 解决 这 个 
问题 ， 但 是 它 会 缓存 从 应 用 程序 启动 开始 的 所 有 事件 ， 所 以 不 太 适 合 长 期 运行 的 进程 。 如 
果真 的 有 订阅 者 必须 接收 到 所 有 的 消息 ， 那 么 要 确保 它 在 JMS 消息 监听 器 初始 化 之 前 就 进 
行 订 阅 。 除 此 之 外 ， 我 们 的 消息 监听 器 还 有 一 个 concurrency="1" 参数 ， 它 能 确保 Subject 
不 会 在 多 个 线程 中 被 调用 。 作 为 赫 代 方案 ， 你 还 可 以 使 用 Subject.toSerialized()。 


补充 一 下 ，Subject 易于 上 手 ， 但 是 使 用 一 段 时 间 之 后 很 容易 出 现 问题 。 在 这 个 特定 场景 
我 们 可 以 很 容易 地 将 Subject 标 换 为 更 惯用 的 RxJava 0bservable， 后 者 可 以 直接 调用 create() 。 


public Observable<Message> observe( 
ConnectionFactory connectionFactory, 
Topic topic) { 
return Observable.create(subscriber -> { 
try { 
subscribeThrowing(subscriber, connectionFactory, topic); 
} catch (JMSException e) { 
subscriber .onError(e); 

















}); 
} 


private void subscribeThrowing( 
Subscriber<? super Message> subscriber, 
ConnectionFactory connectionFactory, 
Topic orders) throws JMSException { 
Connection connection = connectionFactory.createConnection(); 
Session session = connection.createSession(true, AUTO_ACKNOWLEDGE); 
MessageConsumer consumer = session.createConsumer(orders); 
consumer .setMessageListener(subscriber: :onNext); 
subscriber .add(onUnsubscribe(connection)); 
connection. start(); 


I 


private Subscription onUnsubscribe(Connection connection) { 
return Subscriptions.create(() -> { 


try { 





connection.close(); 
} catch (Exception e) { 
log.error("Can't close", e); 


]); 
} 
JMS API 提供 了 两 种 从 代理 (broker) 接收 消息 的 方式 : 一 种 是 通过 阻塞 的 receive() 方 
法 以 同步 的 方式 接收 ， 另 一 种 是 通过 MessageListener 进行 非 阻塞 接收 。 非 阻塞 的 API 有 
很 多 优点 ， 比 如 占用 的 资源 (如 线程 和 栈 内 存 ) 更 少 。 同 时 ， 它 与 Rx 编程 风格 更 加 一 致 。 
在 这 里 ， 不 再 创建 MessageListener 实例 并 从 它 的 内 部 调用 订阅 者 ， 而 是 采用 方法 引用 实 
现 更 简洁 的 语法 。 


consumer .setMessagelistener(subscriber: :onNext) 


同时 ， 还 要 清理 资源 和 处 理 异 常 。 这 个 很 小 的 转换 层 能 够 让 我 们 很 便利 地 消费 JMS 消息 ， 
而 不 必 担 心 API 的 内 部 细 闻 。 如 下 是 使 用 流行 的 ActiveMQ 消息 代理 的 样 例 ， 该 代理 在 本 
地 运行 。 













































































import org.apache.activemq.ActiveMQConnectionFactory; 
import org.apache.activemq.command.ActiveMQTopic; 


ConnectionFactory connectionFactory = 
new ActiveMQConnectionFactory("tcp://\localhost:61616"); 
Observable<String> txtMessages = 
observe(connectionFactory, new ActiveMQTopic("orders")) 
.Cast(TextMessage.class) 
.flatMap(m -> { 
try { 
return Observable.just(m.getText()); 
} catch (JMSException e) { 
return Observable.error(e); 
} 
]); 
JMS 和 JDBC 类 似 ， 同 样 因为 使 用 大 量 的 检查 型 异常 JMSException 而 广 受 诉 病 ， 即 便 是 针 
对 TextMessage 调用 getText() 也 不 例外 。 为 了 恰当 地 处 理 错误 (参见 7.1 节 )， 我 们 使 用 
flatMap() 并 包装 异常 。 从 这 里 开始 ， 就 可 以 将 JMS 消息 流 视 为 其 他 任何 异步 和 非 阻 塞 的 
流 。 值 得 一 提 的 是 ， 这 里 使 用 了 cast() 操作 符 。 这 个 操作 符 会 将 上 游 的 事件 转换 为 指定 的 
类 型 ， 如 果 出 现 失败 ， 将 会 调用 onError()。cast() 基本 上 就 是 一 个 特殊 的 map() 操作 符 ， 
它 的 行为 类 似 于 map(x -> (TextMessage)x)。 


4.8 定期 轮 询 以 获取 变更 


你 可 能 遇 到 的 最 糟糕 的 阻塞 式 API 要 求 轮 询 变更 。 这 种 API 不 会 提供 任何 推送 变更 的 机 
制 ， 甚 至 没有 回调 或 永久 阻塞 机 制 。 这 种 API 提供 的 唯一 机 制 就 是 请 求 当 前 状态 ， 然 后 由 
你 来 判断 它 是 否 与 之 前 的 状态 有 差异 。RxJava 有 一 些 非 常 强大 的 操作 符 ， 借 助 它们 ， 可 以 
将 给 定 的 API 转换 为 Rx 风格 。 接 下 来 考虑 一 个 简单 的 方法 ， 它 会 返回 一 个 代表 当前 状态 
的 值 ， 例 如 Long getorderBookLength()。 为 了 跟踪 它 的 变化 ， 必 须要 频繁 地 调用 这 个 方法 
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并 捕获 变更 。 在 RxJava 中 ， 我 们 可 以 借助 非常 基本 的 操作 符 组 合 实现 这 一 点 ， 如 下 所 示 。 


Observable 
.interval(10, TimeUnit.MILLISECONDS) 
.map(x -> getOrderBookLength()) 
.distinctUuntilChanged() 


首先 ， 每 10 毫秒 ， 我 们 就 会 人 为 地 生成 一 个 Long 值 ， 使 用 它 作为 基础 的 计时 计数 器 。 对 
于 每 个 这 样 的 值 (每 10 毫秒 生成 一 个 ) ， 都 调用 getorderBookLength()。 但 是 ， 前 面 提 及 
的 方法 并 不 会 变化 得 那么 频繁 ， 而 且 我 们 不 希望 订阅 者 接收 到 大 量 无 关 的 状态 变更 。 幸 
好 ， 可 以 只 使 用 distinctuntilChanged()，RxJava 会 透明 地 跳 过 getorderBookLength() 返 
回 的 Long 值 ， 那 些 值 自从 上 次 调用 以 来 没有 发 生变 化 ， 如 图 4-3 的 弹 珠 图 所 示 。 
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在 这 个 模式 的 使 用 上 ， 我 们 可 以 更 进一步 。 假 设 你 正在 监视 文件 系统 或 数据 库 表 的 变更 。 
你 唯一 可 以 使 用 的 机 制 就 是 获取 当前 文件 或 数据 库 记 录 的 快照 。 每 次 有 新 的 条 目 ， 你 构建 
的 API 要 通知 所 有 的 客户 端 。 显 然 ， 你 可 以 使 用 java.nio.file.Watchservice 或 数据 库 触 
发 器 ， 但 是 这 里 只 是 作为 辅助 讲解 的 样 例 。 这 次 我 们 还 是 阶段 性 地 获取 当前 状态 的 一 个 快 
照 ， 如 下 所 示 。 
Observable<Item> observeNewItems() { 
return Observable 
.interval(1, TimeUnit.SECONDS) 


.flatMapIterable(x -> query()) 
.distinct(); 

















} 


List<Item> query() { 


// 获 取 文 件 系 统 目 录 或 数据 库 表 的 快照 





distinct() 操作 符 会 保留 流 经 它 的 所 有 条 目的 一 个 记录 (参见 3.4.4 节 )。 如 果 相 同 的 条 目 
第 二 次 出 现 ， 它 就 会 被 忽略 。 这 就 是 我 们 可 以 每 秒 推送 相同 的 Iten 列表 的 原因 。 第 一 次 
出 现 的 时 候 ， 它 们 会 推送 给 下 游 所 有 的 订阅 者 。 但 是 ， 完 全 相同 的 列表 在 1 秒 后 再 次 出 现 
时 ， 由 于 所 有 的 条 目 都 出 现 过 了 ， 所 以 它们 会 被 丢弃 。 如 果 在 某 个 时 间 点 ，query() 返回 
的 列表 包含 了 一 个 额外 的 Item， 那 么 distinct() 就 会 将 其 传递 至 下 游 。 但 是 这 个 Item 下 



































次 出 现 的 时 候 ， 则 会 被 丢弃 。 在 这 种 简单 的 模式 下 ， 我 们 就 可 以 使 用 定期 轮 询 替 换 大 量 
的 Thread.sleep() 调用 和 手动 缓存 。 它 适用 于 很 多 场景 ， 比 如 文件 传输 协议 (File Transfer 
Protocol，FTP) 轮 询 、Web 抓 取 等 。 


4.9 ”RxJava 的 多 线程 


很 多 第 三 方 API 都 是 阻塞 式 的 ， 而 且 我 们 几乎 对 它们 无 能 为 力 。 我 们 可 能 设 有 源 代码 ， 重 写 
会 导致 非常 高 的 风险 。 在 这 种 情况 下 ， 必 须要 学 会 如 何 处 理 阻塞 代码 ， 而 不 是 与 之 缠 斗 。 

RxJava 的 一 个 显著 特征 就 是 声明 式 并 发 ， 而 不 是 命令 式 并 发 。 手 动 创建 和 管理 线程 已 
经 是 过 去 的 事情 了 (参见 A.3 节 )， 大 多 数 人 已 经 开始 使 用 托管 线程 池 了 (比如 借助 
ExecutorService)。 但 是 ，RxJava 更 进一步 : 0bservable 可 以 像 Java 8 中 的 CompletableFuture 
(参见 5.4 节 ) 一 样 是 非 阻塞 的 ， 但 是 与 后 者 不 同 ，0bservable 还 是 延迟 执行 的 。 除 非 进 行 订 
阅 ， 否 则 设计 良好 的 0bservable 不 会 执行 任何 操作 。 而 0bservable 的 威力 并 不 仅 限于 此 。 


异步 的 0bservablte 能 够 从 不 同 的 线程 调用 Subscriber 回调 方法 (比如 onNext())。 回 忆 一 
下 2.4.1 节 ， 我 们 讨论 过 如 果 subscribe() 是 阻塞 的 ， 它 会 一 直 等 待 ， 直 到 所 有 的 通知 到 达 。 
实际 中 ， 大 多 数 的 Observable 来 自 本 身 就 有 异步 特征 的 事件 源 。 整 个 第 5 章 都 会 阐述 这 样 
的 0bservable。 即 便 是 4.7 节 中 的 简单 JMS 样 例 ， 也 使 用 了 JMS 规范 中 的 内 置 的 、 非 阻塞 
的 API (MessageListener 接口 )。 尽 管 在 类 型 系统 上 没有 强制 要 求 ， 但 是 很 多 0bservable 
一 开始 就 是 异步 的 ， 而 且 也 应 当 假 设 它 们 都 是 异步 的 。 当 0bservable.create() 中 的 lambda 
表达 式 没 有 任何 异步 进程 或 流 作为 支撑 时 ， 阻 塞 式 的 subscribe( ) 方法 很 少 用 到 。 但 是 ， 默 
认 情 况 下 (使 用 create()) ， 所 有 的 逻辑 都 会 在 客户 端 线程 〈 即 进行 订阅 的 线程 ) 中 执行 。 
如 果 你 只 是 在 create() 回调 中 直接 使 用 onNext()， 那 么 不 会 涉及 任何 的 多 线程 和 并 发 。 


如 果 遇 到 这 种 不 太 符 合 常规 的 Observable， 我 们 可 以 声明 式 地 选择 所 谓 的 Scheduler， 它 
会 被 用 来 发 布 值 。 在 CompletableFuture 中 ， 我 们 无 法 控制 底层 的 线程 ，API 会 做 出 决 
策 ;， 在 最 精 糕 的 情况 下 ， 我 们 甚至 不 能 覆盖 它 。RxJava 很 少 独自 做 这 样 的 决策 ， 它 会 选 
择 一 种 安全 的 默认 做 法 : 使 用 客户 端 线程 ， 不 去 涉及 多 线程 。 为 了 更 好 地 介绍 本 章 内 容 ， 
我 们 会 使 用 一 个 非常 简单 的 日 志 “ 库 ”。“ 它 会 打印 当前 线程 的 信息 ， 以 及 使 用 System， 
currentTimeMillis() 获取 的 从 程序 启动 开始 持续 的 毫秒 数 ， 如 下 所 示 。 
void log(Object label) { 
System.out.printLn( 
System.currentTimeMillis() - start + "\t| "+ 


Thread.currentThread().getName() + "\t| "+ 
label); 



































































































































} 


4.9.1 调度 器 是 什么 


RxJava 是 并 发 无 关 的 ， 它 本 身 并 没有 引入 并 发 。 但 是 ， 它 将 一 些 用 来 处 理 线程 的 抽象 暴 
露 给 了 终端 用 户 。 同 时 ， 离 开 了 并 发 ,一些 特定 的 操作 符 (参见 4.9.6 节 ) 也 无 法 正常 





























注 4: 显然 ， 对 于 任何 一 个 实际 的 程序 ， 你 会 使 用 产品 级 的 日 志 系 统 ， 如 Logback 或 Log4J 2。 
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运行 。 你 唯一 需要 关注 的 是 Scheduler 类 ， 而 它 非 常 简 单 。 在 理念 上 ， 它 与 java.util. 

concurrent 中 的 ScheduLedExecutorService 非常 相似 它 能 够 执行 任意 的 代码 块 ， 这 些 

代码 可 能 是 在 未 来 运行 的 。 但 是 ， 为 了 满足 Rx 的 契约 ， 它 提供 了 一 些 细 粒 度 的 抽象 。 更 

深入 的 信息 ， 你 可 以 参考 本 节 的 “调度 器 实现 细节 概览 ”部 分 。 

Scheduler 会 在 创建 特定 类 型 的 Observables 时 ， 与 subscribe0n() 和 observeon() 操作 符 

协同 使 用 。 调 度 器 会 创建 worker 实例 ， 并 由 后 者 负责 进行 调度 和 运行 代码 。RxJava 需要 

调度 代码 的 时 候 ， 它 会 首先 请 求 Scheduler 提供 一 个 Worker， 然 后 借助 该 worker 调度 后 续 

的 任务 。 后 文 会 有 该 API 的 样 例 ， 但 首先 来 熟悉 一 下 可 用 的 内 置 调度 器 。 

口 Schedulers.newThread() 
每 当 通 过 subscribe0n() 或 observeon() 请 求 这 个 调度 器 时 ， 它 都 会 启动 一 个 新 的 线 
程 。newThread() 通常 并 不 是 很 好 的 可 选 方案 。 这 不 仅 是 因为 启动 线程 涉及 延迟 ， 还 因 
为 这 个 线程 并 不 能 被 重用 。 在 这 种 情况 下 ， 必 须要 为 线程 预先 分 配 栈 空间 (通常 大 约 

在 1 MB 左右， 可 以 由 JVM 的 -xss 参数 来 进行 控制 )， 操 作 系 统 必 须要 局 动 一 个 新 的 
本 机 线程 。worker 完成 的 时 候 ， 线 程 就 会 终止 。 只 有 任务 是 非常 粗 粒度 的 情况 下 ， 这 
种 调度 器 才 会 有 用 武之 地 : 这 种 任务 需要 耗费 很 长 时 间 才 能 完成 。 但 是 这 样 的 任务 数量 
很 少 ， 所 以 线程 被 重用 的 可 能 性 也 很 小 ， 参 见 A.2 节 。 在 实践 中 ， 下 述 的 Schedulers. 
io() 通常 是 更 好 的 选择 。 

口 Schedulers.io() 
这 个 调度 器 类 似 于 newThread()， 但 是 它 会 回收 已 启动 的 线程 ,这些 线程 可 以 用 
来 处 理 未 来 的 请 求 。 这 个 实现 的 运行 方式 类 似 于 java.util.concurrent 中 具有 
无 限 线 程 池 的 ThreadPoolExecutor。 每 次 请 求 一 个 新 的 Worker， 要 么 启动 一 个 
新 的 线程 (并 且 随 后 会 在 一 段 时 间 内 维持 空 闪 状态 )， 要 么 就 重用 空间 的 线程 。 
将 其 命名 为 io() 并 非 巧 合 。 考 虑 将 这 个 调度 器 用 到 IO 密集 同时 需要 很 少 CPU 资源 的 
任务 上 。 然 而 ， 这 样 的 任务 可 能 会 耗费 相当 长 的 时 间 等 待 网 络 和 磁盘 。 因 此 ， 比 较 好 的 
做 法 是 使 用 相对 比较 大 的 线程 地 。 不 过 ， 对 于 任何 类 型 的 无 限制 资源 都 要 非常 小 心 。 如 
果 遇 到 慢 速 或 无 响应 的 外 部 依赖 ， 比 如 Web 服务 ，io() 将 会 启动 数量 庞大 的 线程 ， 从 
而 导致 应 用 程序 无 法 响应 。 人 参见 8.2 节 ， 了 解 更 多 处 理 这 种 问题 的 细节 。 

口 Schedulers.computation() 
如 果 任 务 是 CPU 密集 型 ， 那 么 你 应 该 使 用 计算 调度 器 ， 这 种 类 型 的 任务 需要 计算 能 
但 是 没有 阻塞 式 代码 〈 从 磁盘 读 入 、 网 络 访问 、 休 眠 、 等 待 锁 等 )。 因 为 在 调度 器 上 
执行 这 样 的 任务 都 会 希望 充分 利用 CPU 核心 ， 所 以 即便 并 行 执行 的 任务 数量 大 于 可 用 
核心 的 数量 ， 也 不 会 带 来 太 大 的 价值 。 鉴 于 此 ，computation() 调度 器 默认 会 将 并 行 运 
行 的 线程 数量 限制 为 availableProcessors() 方法 返回 的 值 ， 这 个 方法 来 源 于 Runtime. 
getRuntime() 工具 类 。 


如 果 基 于 某 些 原因 ， 你 需要 的 线程 数量 与 默认 值 不 相同 ， 那 么 可 以 使 用 rx.scheduler. 
max-computation-threads 系统 属性 。 使 用 数量 更 少 的 线程 能 够 确保 即便 是 在 高 负载 的 
情况 下 ， 也 会 始终 有 一 个 或 多 个 CPU 核心 处 于 空闲 状态 。 这 样 能 够 避免 computation() 
线程 池 使 服务 器 处 于 饱和 状态 。 我 们 无 法 让 计算 线程 的 数量 超过 CPU 核心 的 数量 。 









































































































































0 会 在 每 个 线程 前 面 使 用 一 个 无 界 队列 ， 所 以 如 果 任 务 已 经 调度 了 ， 但 是 
当前 所 有 的 核心 均 被 占用 ， 那 么 它们 将 会 排队 。 在 负载 高 峰 时 段 ， 这 个 调度 器 能 够 限制 
线程 的 数量 ， 但 是 每 个 线程 前 面 的 队列 将 会 持续 增长 。 


幸好 ,借助 内 置 的 操作 符 ， 尤 其 是 4.9.5 节 将 要 介绍 到 的 observe0n()， 能 够 确保 
Scheduler 不 会 超载 。 


口 Schedulers.from(Executor executor) 
Scheduler 内 部 要 比 java.util.concurrent 包 中 的 Executor 更 为 复杂 ， 所 以 需要 一 个 独 
立 的 抽象 。 但 是 它们 在 理念 上 非常 相似 ， 所 以 有 一 个 能 将 Executor 转换 为 Scheduler 的 
包装 器 也 就 在 情理 之 中 了 ， 这 个 包装 器 使 用 的 是 from() 工厂 方法 ， 如 下 所 示 。 
import com.google.common.util.concurrent.ThreadFactoryBuilder; 


import rx.Scheduler; 
import rx.schedulers.Schedulers; 


















































import java.util.concurrent.ExecutorService; 
import java.util.concurrent.LinkedBlockingQueue; 
import java.util.concurrent.ThreadFactory; 
import java.util.concurrent.ThreadPoolExecutor; 


/11... 


ThreadFactory threadFactory = new ThreadFactoryBuilder() 
.SetNameFormat("MyPool-%d") 
.build(); 

Executor executor = new ThreadPooLExecutor( 
10, //corePoolSize 
10，//maximumPooLSize 
OL, TimeUnit.MILLISECONDS, //keepAliveTime, unit 
new LinkedBlockingQueue<>(1000), //workQueue 
threadFactory 

); 


Scheduler scheduler = Schedulers.from(executor); 


这 里 故意 使 用 了 比较 元 长 的 语法 来 创建 ExecutorService， 而 没有 使 用 如 下 更 为 简洁 的 版 本 。 


import java.util.concurrent.Executors; 


/Jae 
ExecutorService executor = Executors.newFixedThreadPool(10); 


这 种 方式 尽管 看 上 去 很 有 吸引 力 ， 但 是 Executors 工厂 类 硬 编码 了 一 些 默 认 值 。 在 企业 
级 应 用 程序 中 ， 这 种 做 法 是 不 可 行 的 ， 甚 至 可 以 说 是 危险 的 。 例 如 ， 它 使 用 了 无 界 的 
LinkedBLockingQueue， 这 种 队列 可 以 无 限 增长 ， 如 果 有 大 量 未 完成 的 任务 ， 这 将 会 导致 
OutOfMemoryError。 另 外 ， 默 认 的 ThreadFactory 会 使 用 毫 无 意义 的 线程 名 ， 比 如 pootL- 
5-thread-3。 在 诊断 和 分 析 线 程 转 储 的 时 候 ， 恰 当 的 线程 名 是 非常 宝贵 的 工具 。 从 头 实现 
ThreadFactory 有 些 麻烦 ， 所 以 使 用 了 Guava 的 ThreadFactoryBuilder。 如 果 你 对 如 何 优化 
和 更 恰当 地 使 用 线程 池 感 兴趣 ， 可 以 参考 A.3 节 。 对 于 处 理 高 负载 的 项 目 ， 建 议 采 用 精心 
配置 的 Executor 来 创建 调度 器 。 但 是 ，RxJava 无 法 控制 Executor 中 独立 创建 的 线程 ， 所 
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以 它 无 法 对 线程 进行 锁定 〈 也 就 是 ， 尽 量 让 相同 的 任务 在 同一 个 线程 上 执行 ， 从 而 提升 缓 
存 本 地 化 的 效果 )。 这 个 Scheduler 只 能 确保 每 个 Scheduter .Worker (参见 本 节 的 “调度 器 
实现 细节 概览 ”部 分 ) 会 按照 顺序 来 处 理事 件 。 
口 Schedulers.immediate() 
Schedulers.immediate() 是 一 个 特殊 的 调度 器 ， 它 会 以 阻塞 的 方式 在 客户 端 线程 中 调用 
某 个 任务 ， 而 不 是 采用 异步 的 方式 。 使 用 这 个 调度 器 并 没有 太 大 的 意义 ， 除 非 你 的 API 
需要 提供 一 个 调度 器 ， 否 则 你 完全 可 以 直接 使 用 0bservable 的 默认 行为 ， 根 本 不 涉及 
任何 线程 。 实 际 上 ， 通 过 immediate() Scheduler 订阅 一 个 Observable ( 稍 后 会 详细 介 
绍 ) 的 效果 通常 与 不 使 用 任何 调度 器 进行 订阅 的 效果 完全 一 样 。 一 般 情 况 下 ， 要 避免 使 
用 这 个 调度 器 ， 因 为 它 会 阻塞 调用 ， 而 且 用 途 有 限 。 
口 Schedulers.trampoline() 
trampoline() 与 immediate() 非常 相似 ， 它 也 在 相同 的 线程 中 调度 任务 ， 实 际 上 是 阻塞 
式 的 。 但 是 与 immediate() 不 同 ， 使 用 trampoline() 时 ， 后 续 的 任务 会 在 所 有 已 调度 的 
任务 全部 完成 之 后 才 开始 执行 。immediate() 会 立即 执行 给 定 的 任务 ， 而 trampoline() 
则 会 等 待 当前 的 任务 完成 。Trampoline 是 函数 式 编程 中 的 一 种 模式 ， 人 允许 实现 递归 ， 而 
不 会 出 现 无 限 增长 的 调用 栈 。 这 最 好 通过 一 个 例子 来 进行 阐述 ， 如 下 所 示 。 首 先 使 用 
immediate()。 注 意 这 里 没有 直接 与 Scheduler 进行 交互 ， 而 古 创建 了 一 个 Worker。 这 
对 你 学 习 本 节 的 “调度 器 实现 细节 概览 ”部 分 会 有 一 定 帮助 。 
Scheduler scheduler = Schedulers.immediate(); 
Scheduler .Worker worker = scheduler.createWorker(); 


















































log("Main start"); 
worker.schedule(() -> { 
log(" Outer start"); 
sleepOneSecond(); 
worker.schedule(() -> { 
log(" Inner start"); 
sleepOneSecond(); 
log(" Inner end"); 
]); 
log(" Outer end " ) ; 
]); 
log("Main end"); 
worker .unsubscribe(); 


输出 完全 符合 预期 ,实际 上 可 以 将 schedule() 替换 成 简单 的 方法 调用 。 


1044 | main | Main start 
1094 | main | Outer start 
2097 | main | Inner start 
3097 | main | Inner end 
3100 | main | Outer end 
3100 | main | Main end 


在 0uter 代码 块 中 ， 我 们 使 用 schedule() 来 调度 Inner 代码 块 ，Inner 代码 块 会 立即 被 调用 并 
中 断 对 0uter 任务 的 调用 。Inner 完成 之 后 ， 控 制 权 会 重新 回 到 0uter。 再 次 强调 ， 这 只 是 以 











比较 复杂 的 方式 利用 immediate() Scheduler 间接 实现 了 阻塞 式 的 任务 调用 。 但 是 ， 如 果 将 
Schedulers.immediate() 替换 为 ScheduLers.trampoLine() 会 怎么 样 ? 输出 将 会 有 很 大 的 差异 。 


1030 
1096 
2101 
2101 
3101 
3101 





main 
main 
main 
main 
main 
main 


Main start 
Outer start 
Outer end 

Inner start 
Inner end 
Main end 





























worker.schedule(() -> { 
log(" Outer start"); 
sleepOneSecond(); 
worker.schedule(() -> { 
log(" Middle start"); 
sleepOneSecond(); 
worker.schedule(() -> { 
log(" Inner start"); 
sleepOneSecond(); 
log(" Inner end"); 


}); 


log("Main end"); 


]); 
log(" Middle end"); 


}); 


log(" Outer end"); 





来 自 immediate() Scheduler 的 Worker 输出 如 下 所 示 。 





1029 
1091 
2093 
3095 
4096 
4099 
4099 
4099 


main 
main 
main 
main 
main 
main 
main 
main 


Main start 
Outer start 
Middle start 
Inner start 
Inner end 
Middle end 
Outer end 
Main end 


来 自 trampoline() Worker 的 输出 如 下 所 示 。 





1041 
1095 
2099 
2099 
3101 
3101 
4102 
4102 


main 
main 
main 
main 
main 
main 
main 
main 


Main start 
Outer start 
Outer end 

Middle start 
Middle end 
Inner start 
Inner end 
Main end 


E 解 了 它们 的 差异 ， 如 下 所 示 。 


在 这 里 ，0uter 完成 之 后 ，Inner 才 会 启动 。 这 是 因为 Inner 任务 会 在 trampoline() Scheduler 
排队 ， 而 此 时 该 调度 器 已 经 被 0uter 任务 占据 了 。outer 完成 之 后 ， 队 列 中 的 第 一 个 任务 
(Inner) 就 会 开始 执行 。 我 们 可 以 更 进一步 ， 确 保 你 型 


log("Main start"); 
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口 ScheduLers .test() 
这 个 Scheduler 只 用 来 进行 测试 ， 它 不 能 在 生产 代码 中 使 用 。 它 的 主要 优势 在 于 能 
够 任意 推进 时 钟 ， 模 拟 时 间 的 推移 。7.2.2 节 会 对 TestSchedutLer 进行 更 详细 的 描述 。 
Scheduler 本 身 并 没有 太 大 的 意思 ， 如 果 你 想 要 探寻 它们 内 部 是 如 何 运行 的 ， 以 及 如 何 
实现 自己 的 调度 器 ， 那 么 请 阅读 下 面 的 内 容 。 


调度 器 实现 细节 概览 











本 节 的 内 容 完 全 是 可 选 的 ， 如 果 你 对 实现 细节 不 感 兴 趣 ， 可 以 直接 跳 到 
4.9.2 节 。 


Scheduler 不 仅 将 任务 与 它们 的 执行 解 耦 (一 般 通 过 将 它们 在 另外 的 线程 中 运行 来 实现 )， 它 
还 将 时 钟 抽象 了 出 来 , 这 一 点 在 7.2.1 节 将 会 做 进一步 前 述 。 相 对 于 ScheduledExecutorService 
来 说 ，Scheduler 的 API 更 简洁 一 些 ， 如 下 所 示 。 


abstract class Scheduler { 
abstract Worker createWorker(); 


Long now(); 
abstract static class Worker implements Subscription { 
abstract Subscription scheduLe(Actiong0 action); 


abstract Subscription schedule(Action0 action, 
Long delayTime, TimeUnit unit); 


Long now(); 
} 


RxJava 想 要 调度 一 个 任务 时 (一般 会 在 后 台 执 行 ， 但 并 非 必须 如 此 )， 它 必须 首先 请 求 一 
个 worker 实例 。 借 助 worker， 既 可 以 不 加 延迟 地 调度 任务 ， 也 可 以 在 未 来 的 某 个 时 间 点 
调度 任务 。Scheduler 和 Worker 都 有 一 个 可 重 写 的 时 间 源 (now() 方法 ) ， 这 个 方法 用 来 决 
定 给 定 的 任务 要 何 时 运行 。 简 单 地 说 ， 你 可 以 将 Scheduler 视 为 线程 地， 而 将 Worker 视 为 
池 中 的 线程 。 

Scheduler 和 Worker 的 分 离 是 非常 必要 的 。 这 样 就 能 很 容易 地 实现 Rx 契约 要 求 的 一 些 指 
导 原 则 ， 即 顺序 调用 Subscriber 的 方法 ， 而 不 是 并 发 调用 。Worker 的 契约 提供 了 这 样 的 功 
能 : 在 相同 worker 上 调度 的 任务 永远 不 会 并 发 运行 。 但 是 ， 来 自 同一 个 Scheduler 的 独立 
Worker 可 以 很 好 地 并 发 运行 。 

不 再 讨论 API， 让 我 们 分 析 一 下 已 有 Scheduler 的 源 代码 ， 即 RxAndroid 项 目 中 的 
HandlerScheduler。 这 个 Scheduler 会 在 Android 的 UI 线程 中 运行 所 有 调度 任务 ， 更 新 用 
户 界面 的 操作 也 只 能 在 这 个 线程 中 运行 (参见 8.1 节 )。 这 类 似 于 Swing 中 的 事件 分 发 线程 
(Event Dispatch Thread，EDT)， 对 窗口 和 组 件 的 大 多 数 更 新 都 要 在 专门 的 线程 (EDT) 中 
运行 。 毫 不 意外 的 是 ， 针 对 Swing 也 有 一 个 名 为 RxSwing 的 项 目 。 















































package rx.android.schedulers; 


import 
import 
import 
import 
import 
import 
import 


import 


public 


android.os.Handler; 

android.os.Looper; 

rx.Scheduler; 

rx.Subscription; 

rx.functions.ActionO; 
rx.internal.schedulers.ScheduledAction; 
rx.subscriptions.Subscriptions; 


java.util.concurrent.TimeUnit; 


final class SimplifiedHandlerScheduler extends Scheduler { 


@Override 
public Worker createWorker() { 


} 


return new HandlerWorker(); 


static class HandlerWorker extends Worker { 


private final Handler handler = new Handler(Looper .getMainLooper()); 


@Override 

public void unsubscribe() { 
// 马 上 会 实现 …… 

} 


@Override 

public boolean isUnsubscribed() { 
// 马 上 会 实现 …… 
return false; 


} 


@Override 

public Subscription schedule(final Actiong action) { 
return schedule(action, 0, TimeUnit.MILLISECONDS); 

} 


@Override 

public Subscription schedule( 

Action0 action, long delayTime, TimeUnit unit) { 
ScheduledAction scheduledAction = new ScheduledAction(action); 
handler .postDelayed(scheduledAction, unit.toMillis(delayTime)); 


scheduledAction.add(Subscriptions.create(() -> 
handler .removeCallbacks(scheduledAction))); 


return scheduledAction; 


面 的 代码 片段 是 从 RxAndroid 抽取 出 来 的 一 个 不 太 完整 的 类 ， 只 是 为 了 便于 知识 的 讲解 。 
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现在 ，Android API 的 细节 并 不 重要 。 这 里 ， 每 次 在 HandlerWorker 上 调度 任务 ， 代 码 块 都 
会 被 传递 到 一 个 特殊 的 postDelayed() 方法 中 ， 这 个 方法 会 在 专门 的 Android 线程 中 执行 
代码 。 这 样 的 线程 只 有 一 个 ， 因 此 不 仅仅 是 某 个 worker 内 部 的 事件 是 序列 化 执行 的 ， 所 有 


Worker 的 事件 都 是 如 此 。 




















action 在 付 诸 执行 之 前 ， 我 们 使 用 ScheduledAction 对 它 进行 包装 ， 它 同时 实现 了 
Runnable 和 Subscription。 如 果 可 能 ，RxJava 始终 都 会 延迟 执行 ， 这 一 原则 同样 适用 于 调 
度 任务 。 如 果 基 于 某 种 原因 ， 你 决定 取消 执行 给 定 的 action (这 适用 于 action 调度 到 未 
来 的 某 个 时 间 点 执行 ， 而 不 是 立即 执行 的 场景 )， 那 么 只 需要 根据 schedule() 方法 返回 的 





















































Subscription 实例 ， 运 行 其 unsubscribe() 方法 即 可 。Worker 负责 恰当 地 处 理 取消 订阅 的 
相关 工作 (至 少 它 会 尽 最 大 努力 处 理 好 )。 


客户 端 代码 也 可 以 从 Worker 级 别 通过 unsubscribe() 全 部 取消 订阅 。 这 样 会 取消 所 有 


排队 的 任务 并 释放 worker， 便 于 底层 的 线程 稍 后 进行 重用 。 如 下 的 代码 片段 增强 























SimpLifiedHhandterScheduLer， 为 其 添加 了 worker 取消 订阅 的 流程 (只 包含 修改 过 的 代码 )。 


private CompositeSubscription compositeSubscription 
new CompositeSubscription(); 


@Override 


public void unsubscribe() { 
compositeSubscription.unsubscribe(); 


} 


@Override 


public boolean isUnsubscribed() { 
return compositeSubscription.isUnsubscribed(); 


} 


@Override 


public Subscription scheduLe(Action0 action, long delayTime, TimeUnit unit) { 
if (compositeSubscription.isUnsubscribed()) { 
return Subscriptions.unsubscribed(); 


} 


final ScheduledAction scheduledAction = new ScheduledAction(action); 
scheduledAction.addParent(compositeSubscription); 
compositeSubscription.add(scheduledAction); 


handler .postDelayed(scheduledAction, unit.toMillis(delayTime)); 


scheduledAction.add(Subscriptions.create(() -> 
handler .removeCallbacks(scheduledAction))); 


return scheduledAction; 


} 
我 们 在 2.3 节 中 探讨 了 
Subscription 是 众多 可 月 
模式 ) ， 在 CompositeSub 





Subscription 接口 ， 但 是 并 没有 








真正 展开 实现 细节 。Composite- 








日 实现 中 的 一 个 ， 它 本 身 只 是 子 Subscription 的 容器 ( 即 组 合 设 计 
scription 上 取消 订阅 的 操作 意味 着 要 取消 对 所 有 子 Subscription 
的 订阅 。 你 还 可 以 添加 和 移 除 CompositeSubscription 管理 


的 子 Subscription。 
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在 我 们 自 定 义 的 Scheduler 中 ，CompositeSubscription 用 来 跟踪 前 面 schedule() 方法 调 
用 形成 的 所 有 Subscription (参见 compositeSubscription.add(scheduledAction))。 另 


一 方面 ， 子 ScheduledAction 还 需要 知道 其 父 Subscription (参见 addParent())， 这 











样 ， 操 作 完 成 或 取消 的 时 候 ， 它 就 能 够 将 自己 移 除 。 否 则 ， 
客户 端 代码 决定 不 需要 某 个 Handter Worker 实例 时 ， 它 会 对 寺 


Subscription。 


取消 订阅 的 操作 会 传递 到 所 有 未 完成 的 子 Subscription (如 果 存在 )。 


以 上 就 是 对 











RxJava 中 Scheduler 的 简短 








。 在 日 常 工作 中 ， 这 些 内 部 细节 用 处 才 
实际 上 ， ee te ed ese ede 
看 一 下 Scheduler 是 如 何 解 决 Rx 中 众多 的 和 





F 发 问题 的 。 


4.9.2 ”使 用 subscribeon() 进 行 声 明 式 订阅 


绍 过 ，subscribe() 默认 使 用 客户 端的 线程 。 扼 要 重 述 ， 如 下 是 最 简 
能 ， 不 涉及 任何 的 线程 。 


Observable<String> simple() { 

return Observable.create(subscriber 
log("Subscribed"); 
subscriber .onNext("A"); 
subscriber .onNext("B"); 
subscriber .onCompleted(); 


2.4.1 节 介 


}); 


11... 


3? 


log("Starting"); 

final Observable<String> obs = simple(); 
log("Created"); 

final Observable<String> obs2 = obs 


); 


.map(X 


-> X) 


.filter(x -> true); 
log("Transformed"); 

obs2.subscribe( 

x -> log("Got " + X)， 
Throwable: :printStackTrace, 
-> log("Completed") 


(0) 


log("Exiting"); 


记录 语句 放 在 了 什么 地 方 ， 然 后 仔细 看 以 下 输出 ， 尤 其 是 哪个 线程 调用 了 打印 


请 注意 日 志 
语句 。 


33 

120 | 
128 | 
133 | 
133 | 
133 | 
133 | 
134 | 


main 
main 
main 
main 
main 
main 
main 
main 


Starting 
Created 
Transformed 
Subscribed 
Got A 

Got B 
Completed 
Exiting 


->{ 














Worker 会 不 断 地 累积 旧 的 子 


其 取消 订阅 。 


接 下 来 ， 





F 不 大 。 
快速 





单 的 订阅 功 
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注意 : 语句 的 顺序 完全 是 可 预测 的 。 首 先 ， 上 述 代码 片段 中 的 每 行 代码 都 在 main 线程 中 运 
行 ， 不 涉及 任何 线程 池 和 异步 事件 的 发 布 。 其 次 ， 乍 看 上 去 ， 代 码 的 执行 顺序 可 能 并 不 十 
分 清晰 。 

程序 启动 的 时 候 ， 它 会 首先 会 打印 出 Starting， 这 一 点 非常 容易 理解 。 在 创建 
observable<String> 实例 之 后 ， 我 们 看 到 了 created 信息 。 请 注意 ,真正 开始 订阅 后 ， 才 
会 随 之 出 现 Subscribed。 如 果 不 调用 subscribe()，0bservable.create() 中 的 代码 块 就 永 
远 不 会 执行 。 另 外 ，map() 和 filter() 操作 符 甚至 没有 任何 可 见 的 副作用 ， 而 Transformed 
消息 出 现在 了 Subscribed 之 前 。 


随后 ， 我 们 接收 到 所 有 发 布 出 来 的 事件 以 及 完成 通知 。 最 后 ， 程 序 打印 出 Exiting， 然 后 
就 可 以 返回 了 。 这 是 一 个 非常 有 意思 的 观察 结果 : 我 们 会 认为 subscribe() 只 是 注册 了 一 
个 回调 ， 而 事件 会 以 异步 的 方式 出 现 。 这 可 能 是 默认 的 假定 。 但 是 ， 在 这 种 场景 中 ， 并 没 
有 涉及 线程 ，subscribe() 实际 上 是 阻塞 的 。 为 什么 要 以 这 种 方式 实现 ? 

在 subscribe() 和 create() 之 间 有 一 个 内 在 却 隐 含 的 连接 。 每 次 在 observabte 上 调用 
subscribe() 的 时 候 ， 就 会 调用 它 的 onsubscribe 回调 方法 (该 方法 包装 了 传递 给 create() 
的 lambda 表达 式 ) 。 它 接收 你 的 Subscriber 作为 参数 。 默 认 情况 下 ， 这 会 在 同一 个 线程 中 
执行 ， 并 且 是 阻塞 的 ， 换 言 之 ， 无 论 在 create() 中 做 什么 ， 都 会 阻塞 subscribe()。 如 果 
你 的 create() 休眠 几 秒 ， 那 么 subscribe() 就 会 阻塞 。 如 果 在 0bservabte.create() 和 你 
的 subscriber (作为 回调 的 lambda 表达 式 ) 之 间 存 在 操作 符 ， 所 有 的 操作 符 也 都 会 在 调 
用 subscribe() 的 线程 中 执行 。RxJava 默认 在 Observable 和 Subscriber 之 间 并 没有 插入 任 
何 的 并 发 基础 设施 。 这 背后 的 原因 在 于 0bservable 一 般 是 由 其 他 并 发 机 制 支撑 的 ， 比 如 事 
件 循 环 或 自 定 义 线程 ， 所 以 Rx 将 控制 权 完全 交 给 你 ， 而 不 做 任何 强加 的 约定 。 


上 面 的 观察 结果 为 介绍 subscribeon() 操作 符 做 好 了 铺垫 。 可 以 将 subscribeon() 放 到 原始 
Observable 和 subscribe() 之 间 的 任意 地 方 ， 通 过 这 种 方式 ， 声 明 式 地 定义 的 OnSubscribe 
回调 方法 会 在 所 选 的 Scheduler 中 执行 。 不 管 在 create() 中 进行 何 种 操作 ， 这 些 任务 都 会 
由 独立 的 scheduler 承担 ， 而 subscribe() 不 会 再 阻塞 。 

log("Starting"); 

final Observable<String> obs = simple(); 


log("Created"); 
obs 

















































































































.SubscribeOn(schedulerA) 
.Subscribe( 
x -> log("Got " + X)， 
Throwable: :printStackTrace, 
() -> log("Completed") 
); 
log("Exiting"); 


35 main | Starting 
112 | main | Created 
123 | main | Exiting 


124 | Sched-A-0 | Got A 
124 | Sched-A-0 | Got B 


| 
| 
| 
123 | Sched-A-0 | Subscribed 
| 
| 
124 | Sched-A-0 | Completed 








不 知 你 是 否 注意 到 ，main 线程 在 0bservablte 发 布 值 之 前 就 已 经 退出 了 。 从 技术 上 讲 ， 日 
志 信 息 的 顺序 无 法 预测 ， 因 为 这 两 个 线程 是 并 发 执行 的 : maiin 会 进行 订阅 并 退出 ， 而 
sched-A-0 会 在 有 人 订阅 后 立刻 发 布 事件 。scheduLerA 和 Sched-A-9 都 来 源 于 如 下 的 示例 调 
度 器 ， 构 建 这 个 调度 器 就 是 为 了 便于 进行 说 明 。 


import static java.util.concurrent.Executors.newFixedThreadPool; 

















ExecutorService poolA = newFixedThreadPool(10, threadFactory("Sched-A-%d")); 
Scheduler schedulerA = Schedulers.from(poolA); 


ExecutorService poolB = newFixedThreadPool(10, threadFactory("Sched-B-%d")); 
Scheduler schedulerB = Schedulers.from(poolB); 


ExecutorService poolC = newFixedThreadPool(10, threadFactory("Sched-C-%d")); 
Scheduler schedulerC = Schedulers.from(poolC); 


private ThreadFactory threadFactory(String pattern) { 
return new ThreadFactoryBuilder() 
.SetNameFormat(pattern) 
.build(); 
I. 


这 些 调度 器 将 会 用 到 所 有 的 样 例 中 ， 不 过 要 记 住 它们 也 非常 容易 。 这 里 有 三 个 独立 的 调度 
器 ， 每 个 都 管理 着 来 自 ExecutorService 的 10 个 线程 。 为 了 让 输出 更 加 直观 ， 每 个 线程 池 
都 有 不 同 的 命名 模式 。 


在 开始 之 前 ， 你 必须 要 知道 ， 在 采用 Rx 的 成 熟 应 用 程序 中 ， 很 少 会 用 到 subscribeon() 。 
正常 情况 下 ，0bservable 源 于 本 来 就 已 经 是 异步 的 源 (如 RxNetty， 参 见 5.1.2 节 ) 或 者 它 
们 本 身 就 已 经 使 用 了 调度 (如 Hystrix， 参 见 8.2 节 )。subscribeon() 仅 用 于 一 些 特殊 的 场 
景 ， 也 就 是 你 已 经 知道 底层 Observable 是 同步 的 (create() 是 阻塞 的 ) 时 候 。 但 是 ， 相 对 
于 在 create() 中 手动 编写 线程 相关 的 代码 ，subscribeon() 是 一 个 好 得 多 的 方案 。 


// 不 要 这 样 做 
Observable<String> obs = Observable.create(subscriber -> { 
log("Subscribed"); 
Runnable code = () -> { 
subscriber .onNext("A"); 
subscriber .onNext("B"); 
subscriber .onCompleted(); 












































}; 
new Thread(code, "Async").start(); 


}); 


上 述 代码 混 请 了 两 个 概念 : 生成 事件 和 选择 并 发 策略 。0bservable 只 应 该 负责 事件 的 生成 
逻辑 ， 而 只 有 客户 端 代 码 才能 对 并 发 性 做 出 正确 的 决策 。 需 要 记 住 ，0bservable 是 延迟 执 
行 的 ， 并 且 是 不 可 变 的 。 在 某 种 意义 上 讲 ，subscribeon() 只 会 影响 下 游 订 阅 者 。 如 果 有 
人 订阅 了 同一 个 0bservable， 但 是 没有 使 用 subscribe0n()， 默 认 不 涉及 任何 并 发 。 


本 章 关 注 的 是 已 有 的 应 用 程序 以 及 如 何 逐 步 引 入 RxJava。 在 这 种 情况 下 ，subscribeon() 
操作 符 非常 有 用 ， 但 是 ， 在 你 掌握 了 Reactive Extensions 并 开始 大 规模 使 用 它们 之 后 ， 
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subscribeon() 的 价值 就 降低 了 。 在 完全 反应 式 的 软件 栈 中 ， 比 如 Nettix， 几 乎 不 会 用 到 
subscribe0n()， 因 为 所 有 的 Observable 都 已 经 是 异步 的 了 。 大 多 数 情况 下 ，0bservabtLe 来 
自 异 步 的 事件 产 ， 并 且 默 认 它 们 都 是 异步 的 。 因 此 ，subscribeon() 的 使 用 场景 非常 有 限 ， 
主要 用 于 完善 现 有 API 和 库 的 工作 。 我 们 在 第 5 章 中 将 会 编写 完全 异步 的 应 用 程序 ， 到 那 
时 就 不 会 显 式 使 用 subscribe0n() 和 Scheduler 了 。 


4.9.3 subscribeon() 的 并 发 性 和 行为 


关于 subscribe0n() 如 何 运 行 ， 有 一 些 很 有 意思 的 细节 。 首 先 ， 好奇 的 读者 可 能 想 知 道 ， 
如 果 在 Observable 和 subscribe() 之 间 调 用 两 次 subscribeon()， 将 会 如 何 运 行 ? 答案 非 
常 简 单 : 最 靠近 原始 observabte 的 subscribeon() 胜出 。 这 具有 重要 的 实际 意义 。 如 果 你 
正在 设计 一 个 API， 并 在 内 部 使 用 了 subscribeon()， 那 么 客户 端 代 码 将 无 法 覆盖 你 选择 的 
ScheduLer。 这 可 以 称 得 上 是 精心 思考 的 设计 决策 ， 毕 竟 ， 只 有 API 的 设计 者 最 了 解 哪个 
Scheduler 更 合适 。 另 一 方面 ， 比 较 好 的 办 法 是 提供 上 述 API 的 重 载 版 本 ， 从 而 允许 覆盖 
API 设计 者 选择 的 Scheduler。 


接 下 来 ， 让 我 们 学 习 一 下 subscribe0n() 的 行为 。 


log("Starting"); 
Observable<String> obs = simple(); 
log("Created"); 

obs 
































.SubscribeOn(schedulerA) 
// 很 多 其 他 的 操作 符 
.SubscribeOn(schedulerB) 
.Subscribe( 
x -> log("Got " + X)， 
Throwable: :printStackTrace, 
() -> log("Completed") 





); 
log("Exiting"); 


如 下 输出 只 会 显示 schedulerA 的 线程 。 


17 | main | Starting 

73 | main | Created 

83 | main | Exiting 

84 | Sched-A-0 | Subscribed 
84 | Sched-A-0 | Got A 

84 | Sched-A-0 | Got B 

84 | Sched-A-0 | Completed 


有 意思 的 是 ， 对 schedulerA 来 说 ，schedulerB 并 非 被 完全 忽略 。schedulerB 也 会 在 很 短 
的 时 间 内 被 用 到 ， 不 过 只 是 用 来 在 schedulerA 上 调度 新 的 操作 ， 而 所 有 的 工作 都 是 由 
schedulerA 完成 的 。 因 此 ， 多 个 subscribeon() 不 仅 会 被 忽略 ， 还 会 引入 一 点 额外 的 开销 。 
说 到 操作 符 ， 本 书 提 到 过 ， 在 新 的 Subscriber 执行 时 ，create() 会 在 提供 的 调度 器 (如果 
有 的 话 ) 中 执行 。 但 是 ,该 由 哪个 线程 来 执行 create() 和 subscribe() 之 间 的 所 有 转换 ? 
默认 情况 下 ， 所 有 的 操作 符 都 会 在 相同 的 线程 (调度 器 ) 中 执行 ， 默 认 不 会 涉及 并 发 。 
































log("Starting"); 
final Observable<String> obs = simple(); 
log("Created"); 
obs 
.do0nNext(this::Log) 
.map(x -> X + '1') 
.do0nNext(this::Log) 
.map(x -> X + '2') 
.SubscribeOn(schedulerA) 
.do0nNext(this::Log) 
.Subscribe( 
x -> log("Got " + X)， 
Throwable: :printStackTrace, 
() -> log("Completed") 
); 
log("Exiting"); 


我 们 在 操作 符 管道 中 添加 了 doonNext()， 以 便 查 看 此 时 哪个 线程 处 于 控制 状态 。subscribeon() 


的 位 置 无 关 紧 要 ， 它 可 以 紧 跟 在 0bservable 后 面 ， 也 可 以 放 在 subscribe() 之 前 。 如 下 的 
输出 结果 并 不 令 人 意外 。 


20 | main | Starting 
104 | main | Created 

123 | main | Exiting 

124 | Sched-A-0 | Subscribed 
124 | Sched-A-0 | A 

124 | Sched-A-0 | Al 

124 | Sched-A-0 | A12 

124 | Sched-A-0 | Got A12 
124 | Sched-A-0 | B 

124 | Sched-A-0 | B1 

124 | Sched-A-0 | B12 

125 | Sched-A-0 | Got B12 





请 注意 观察 如 何 调用 和 生成 A、B 事件 。 这 些 事件 按 顺 序 依 次 通过 调度 器 的 线程 ， 最 后 到 
达 Subscriber。 很 多 刚 接 触 RxJava 的 读者 会 认为 ， 如 果 将 大 量 线程 与 Scheduler 组 合 使 
用 ，RxJava 会 自动 对 事件 进行 分 又 并 发 处 理 ， 并 在 最 后 以 某 种 形式 将 结果 联结 (join) 起 
来 。 但 事实 并 非 如 此 。RxJava 会 为 整个 管道 只 创建 一 个 worker 实例 (参见 4.9.1 节 )， 主 
要 是 为 了 确保 事件 能 够 按 顺序 进行 处 理 。 


这 意味 着 ， 如 果 你 有 一 个 特别 慢 的 操作 符 ， 比 如 map() 操作 符 为 了 转换 流 经 的 事件 需要 从 
磁盘 读 取 数据 ， 那 么 这 个 成 本 高 昂 的 操作 会 在 相同 的 线程 中 运行 。 一 个 糟糕 的 操作 符 会 减 
缓 整个 管道 的 运行 速度 ， 从 生产 者 直到 消费 者 均 不 能 幸免 。 在 RxJava 中 ， 这 是 一 种 反 模 
式 ， 操 作 符 应 该 是 非 阻塞 的 、 快 速 运行 的 ， 并 且 工 作 内 容 越 单纯 越 好 。 

在 这 方面 ,flatMap() 可 以 再 次 施 以 援手 。 与 map() 中 的 阻塞 行为 不 同 ， 我 们 可 以 调 
用 flLatMap() 并 异步 收集 所 有 的 结果 。 因 此 ， 如 果 想 要 实现 真正 的 并 行 ，flatMap() 和 
merge() 操作 符 能 够 达到 这 一 目的 。 但 是 ， 即 便 是 使 用 flatMap()， 也 并 非 那 么 简单 。 假 设 
有 一 个 杂货 店 〈 即 RxGroceries) ， 它 提供 了 购买 商品 的 API， 如 下 所 示 。 
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class RxGroceries { 


显然 ， 在 这 是 





Observable<BigDecimal> purchase(String productName, int quantity) { 
return Observable.fromCallable(() -> 
doPurchase(productName, quantity)); 


= 


BigDecimal doPurchase(String productName, int quantity) { 


Log("Purchasing 


"+ quantity + " " + productName ); 





// 实 际 的 逻辑 在 这 里 
log("Done " + quantity + " " + productName); 


return priceForProduct; 








且 doPurchase() 的 实现 无 关 紧 要 ， 只 需 假 设 它 需 要 一 定 的 时 间 和 资源 才能 完 





成 。 我 们 通过 添加 1 秒 的 休眠 来 模拟 业务 逻辑 ， 如 果 quantity 值 更 大 ， 休 眠 时 间 会 更 长 一 
点 。 在 实际 应 用 程序 中 ， 像 purchase() 方法 返回 的 这 种 阻塞 Observable 并 不 常见 ， 但 是 
为 了 讲解 的 需要 ， 我 们 让 它 保持 这 种 运行 方式 。 购 买 多 件 商品 的 时 候 ， 我 们 想 要 尽 可 能 地 
并 行 处 理 ， 并 在 最 后 计算 所 有 商品 的 总 价 。 第 一 次 尝试 是 徒劳 的 。 

Observable<BigDecimal> totalPrice = Observable 
.just("bread", "butter", "milk", "tomato", "cheese") 
.SubscribeOn(schedulerA) // 有 问题 的 !!! 
.map(prod -> rxGroceries.dopPurchase(prod, 1)) 


.reduce(BigDecimal: :add) 
.single(); 


最 终结 果 是 正确 的 ， 它 是 只 包含 一 个 值 的 bbservable， 也 就 是 通过 reduce() 计算 得 到 的 
总 价 。 对 于 每 种 商品 ， 我 们 调用 了 doPurchase()， 并 将 quantity 设置 为 一 。 但 是 ， 尽 管 
schedulerA 由 10 个 线程 的 池 作 为 支撑 ， 代 码 依然 是 完全 序列 化 执行 的 。 
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1144 
1146 
2146 
2146 
3147 
3147 
4147 
4147 
5148 





Sched-A-0 
Sched-A-0 
Sched-A-0 
Sched-A-0 
Sched-A-0 
Sched-A-0 
Sched-A-0 
Sched-A-0 
Sched-A-0 
Sched-A-0 

















Purchasing 1 bread 
Done 1 bread 
Purchasing 1 butter 
Done 1 butter 
Purchasing 1 milk 
Done 1 milk 
Purchasing 1 tomato 
Done 1 tomato 
Purchasing 1 cheese 
Done 1 cheese 




















请 注意 ， 每 种 商品 都 阻塞 了 后 续 商 品 的 处 理 。 面 包 的 购买 完成 之 后 ， 会 立即 处 理 黄 油 的 购 
买 请 求 ， 但 是 无 法 在 此 之 前 开始 进行 处 理 。 诡 异 的 是 ， 即 便 将 map() 替换 为 flatMap() 也 
没有 任何 的 助 益 ， 输 出 完全 相同 。 


Observable 
.just("bread", "butter", "milk", "tomato", "cheese") 
.SubscribeOn(schedulerA) 

.flatMap(prod -> rxGroceries.purchase(prod, 1)) 
.reduce(BigDecimal: :add) 

.Single(); 














代码 之 所 以 没有 并 行 执 行 ， 原因 就 在 于 这 里 只 有 一 个 事件 流 ， 按 照 设 计 它 们 必须 序列 化 运 
行 。 否 则 ， 你 的 Subscriber 就 需要 感知 并 发 的 通知 (onNext()、onComplete() 等 ) 了 ， 所 
以 这 是 一 个 折 中 的 方案 。 幸 而 ， 惯 用 的 方案 与 之 非常 接近 。 发 布 商品 的 主 0bservablte 不 能 
并 行 化 ， 但 是 对 于 每 种 商品 ， 当 它们 从 purchase() 返回 时 候 ， 我 们 可 以 创建 新 的 、 独 立 的 
Observable。 因 为 是 独立 的 ， 也 就 意味 着 可 以 安全 地 对 它们 进行 并 发 处 理 。 
Observable<BigDecimal> totalPrice = Observable 
.just("bread", "butter", "milk", "tomato", "cheese") 
.flatMap(prod -> 
rxGroceries 
.purchase(prod, 1) 
.SubscribeOn(schedulerA)) 
.reduce(BigDecimal: :add) 
.Single(); 
你 注意 到 subscribeon() 在 哪里 了 吗 ? 主 observabte 并 没有 做 任何 事情 ， 所 以 不 需要 
特殊 的 线程 池 。 但 是 ， 样 例 为 flatMap() 中 创建 的 每 个 子 流 都 提供 了 scheduterA。 每 次 
subscribeOn() 被 调用 ，Scheduter 都 能 返回 一 个 新 的 Worker， 因 此 也 会 有 一 个 单独 的 线程 。 





















































113 | Sched-A-1 | Purchasing 1 butter 
114 | Sched-A-0 | Purchasing 1 bread 
125 | Sched-A-2 | Purchasing 1 milk 
125 | Sched-A-3 | Purchasing 1 tomato 
126 | Sched-A-4 | Purchasing 1 cheese 
1126 | Sched-A-2 | Done 1 milk 

1126 | Sched-A-0 | Done 1 bread 

1126 | Sched-A-1 | Done 1 butter 

1128 | Sched-A-3 | Done 1 tomato 

1128 | Sched-A-4 | Done 1 cheese 


最 后 ， 样 例 实现 了 真正 的 并 发 。 每 个 购买 的 操作 都 会 同时 开始 ， 并 且 最 终 完 成 。flatMap() 
经 过 了 精心 的 设计 和 实现 ， 所 以 它 会 收集 所 有 独立 流 的 事件 并 将 它们 按 顺 序 推送 至 下 游 。 
但 是 ， 正 如 3.1.4 节 介 绍 的 ， 此 时 不 能 再 依赖 下 游 事 件 的 顺序 了 ， 它 们 开始 和 完成 的 顺序 
已 经 与 最 初 发 布 的 顺序 不 同 了 (原始 的 序列 是 从 面包 开始 的 )。 它 们 顺序 抵达 reduce() 操 
作 符 的 时 候 ， 就 已 经 是 序列 化 的 了 ， 并 且 能 够 按 顺 序 执行 。 


到 现在 为 止 ， 你 应 该 已 经 逐渐 摆脱 了 传统 的 Thread 模型 ， 并 且 理 解 了 scheduler 是 如 何 运 

行 的 。 但 是 ， 如 果 你 觉得 还 有 困难 ， 可 以 看 看 如 下 的 简单 类 比 。 

。 没有 Scheduler 的 Observable 就 像 一 个 单线 程 的 程序 ,以 阻塞 式 方 法 在 彼此 之 间 传 递 数 据 。 

。 具有 一 个 subscribeon() 的 0bservable 就 像 在 后 台 Thread 中 启动 了 一 个 大 型 的 任务 。 
Thread 中 的 程序 依然 是 序列 化 的 ， 但 至 少 它 会 在 后 台 运 行 。 

。 如 果 0bservable 使 用 了 flatMap()， 并 日 每 个 内 部 0Observable 都 使 用 了 subscribeon() ， 
那么 其 运行 方式 就 像 是 java.util.concurrent 中 的 ForkJoinpPool， 每 个 子 流 都 是 分 又 执 
行 的 ， 而 flatMap() 是 一 个 安全 的 联结 点 。 

当然 ， 上 述 类 比 仅 适 用 于 阻塞 式 的 0bservable， 而 在 实际 应 用 程序 中 ， 这 种 0bservabte 是 

比较 少见 的 。 如 果 你 的 底层 0bservable 已 经 是 异步 的 ， 那 么 实现 并 发 仅仅 需要 理解 它们 该 

如 何 进 行 组 合 ， 以 及 何 时 进行 订阅 。 例 如 ， 对 两 个 流 进行 merge() 操作 会 并 发 订阅 这 两 个 

流 ， 而 concat() 会 一 直 等 到 第 一 个 流 完 成 才 订 阅 第 二 个 流 。 
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4.9.4 使 用 groupBy() 进 行 批量 请 求 


不 知道 你 是 否 注意 到 了 ， 即 便 商品 的 数量 始终 为 一 ，RxGroceries.purchase() 方法 也 会 接 
收 productName 和 quantity 这 两 个 参数 。 如 果 某 些 商 品 在 货物 清单 上 出 现 了 多 次 ， 意 味 着 
对 它们 有 更 高 的 需求 ， 又 该 怎么 办 ? 最 简单 的 实现 方式 就 是 多 次 发 送 相同 的 请 求 ， 比 如 ， 
多 次 发 送 对 鸡蛋 的 购买 请 求 ， 每 次 只 买 一 个 。 幸 好 ， 可 以 使 用 groupBy()， 以 声明 式 的 方 
式 批 量 处 理 这 样 的 请 求 ， 而 且 声明 式 并 发 依然 适用 。 


import org.apache.commons.Lang3.tupLe.Pair; 

















Observable<BigDecimal> totaLPrice = Observable 
.just("bread", "butter", "egg", "milk", "tomato", 
"cheese", "tomato", "egg", "egg") 
.groupBy(prod -> prod) 
.flatMap(grouped -> grouped 
.count() 
.map(quantity -> { 
String productName = grouped.getKey(); 
return Pair.of(productName, quantity); 


})) 
.flatMap(order -> store 
.purchase(order .getKey(), order .getValue()) 
.SubscribeOn(schedulerA)) 
.reduce(BigDecimal::add) 
.Single(); 


这 段 代码 非常 复杂 ， 所 以 在 介绍 输出 内 容 之 前 ， 让 我 们 先 快速 浏览 一 下 代码 的 内 容 。 首 
先 s 根据 商品 的 名 称 对 其 进行 分 组 ， 所 以 使 用 了 恒 等 国 数 prod -> prod。 它 返回 的 是 看 上 
去 有 点 烦琐 的 0bservabLe<Grouped0bservabLe<String， String>>， 这 本 身 是 没有 什么 问题 
的 。 接 下 来 ，fLatMap() 操作 符 会 接收 每 个 Grouped0bservabtLe<String，String>， 后 者 代 
表 了 具有 相同 名 称 的 所 有 商品 。 例 如 ， 对 于 值 为 "egg" 的 key， 将 会 对 应 ["egg"，"egg"， 
"egg"] Observable。 如 果 groupBy() 使 用 不 同 的 key 生成 国 数 ， 比 如 prod. length()， 那 么 
相同 的 数据 序列 对 应 的 key 就 是 3 了 。 


此 时 ， 在 fLatMap() 中 ， 需 要 构建 一 个 Pair<sString，Integer> 类 型 的 0Observable， 它 代表 
了 每 种 唯一 的 商品 及 其 数量 。count() 和 map() 返回 的 都 是 0bservable， 所 以 一 切 都 满足 

需求 。 第 二 个 fLatMap() 会 接收 Pair<String，Integer> 类 型 的 order， 然 后 进行 购买 ， 这 
一 次 购买 数量 可 以 更 大 一 些 。 输 出 看 上 去 已 经 满足 了 要 求 ， 请 注意 大 订单 会 更 慢 一 些 ， 但 
是 依然 比 多 次 重复 请 求 要 快 。 












































164 | Sched-A-0 | Purchasing 1 bread 
165 | Sched-A-1 | Purchasing 1 butter 
166 | Sched-A-2 | Purchasing 3 egg 
166 | Sched-A-3 | Purchasing 1 milk 
166 | Sched-A-4 | Purchasing 2 tomato 
166 | Sched-A-5 | Purchasing 1 cheese 
1151 | Sched-A-0 | Done 1 bread 

1178 | Sched-A-1 | Done 1 butter 

1180 | Sched-A-5 | Done 1 cheese 

1183 | Sched-A-3 | Done 1 milk 





1253 | Sched-A-4 | Done 2 tomato 
1354 | Sched-A-2 | Done 3 egg 


如 有 果 你 认为 自己 的 系统 能 够 从 这 种 或 其 他 的 批 处 理 方式 中 获 益 ， 那 么 可 以 参考 8.2.4 市 。 





4.9.5 使 用 observeon() 声 明 并 发 
不 管 你 是 否 相 信 ， 在 RxJava 中 有 两 种 方式 来 声明 并 发 ， 即 前 文 所 述 的 subscribe0n() 以 及 



































接 下 来 要 介绍 的 observeon()。 二 者 看 上 去 非常 相似 ， 初 学 者 很 容易 混淆 ， 但 是 它们 的 语 
义 其 实 非常 清晰 合理 。 


subscribeon() 让 我 们 能 够 选择 使 用 哪个 Scheduler 来 触发 OnSubscribe (create() 中 的 
lambda 表达 式 )。 因 此 ，create() 中 的 代码 都 会 被 放 到 一 个 不 同 的 线程 中 ， 例 如 ， 可 以 通 
过 这 种 方式 来 避免 阻塞 主线 程 。 与 之 不 同 的 是 ，observe0n() 在 被 调用 之 后 ， 能 够 控制 该 
由 哪个 Scheduler 触发 下 游 的 Subscriber。 例 如 ， 调 用 create() 发 生 在 io() Scheduler 中 


(通过 subscribeon(io()) 实现 )， 从 而 避免 阳 
须要 在 UI 线程 中 运行 (Swing 和 Android 都 
作 符 和 订阅 者 调用 之 前 调用 observeon()， 六 
传递 进来 。 通 过 这 种 方式 ， 我 们 可 以 使 用 某 个 scheduler 来 处 型 
之 前 的 所 有 操作 符 ， 使 用 其 他 的 Scheduler 来 进行 一 些 转 换 。 让 我 





observeOn() 











例子 来 进行 阐述 ， 如 下 所 示 。 


log("Starting"); 
final Observable<String> obs = simple(); 
log("Created"); 


obs 


.do0nNext(x -> log("Found 1: " + x)) 
.observeOn(schedulerA) 
.do0nNext(x -> log("Found 2: " + x)) 
.Subscribe( 
x -> log("Got 1: " + x), 
Throwable: :printStackTrace, 
() -> log("Completed") 
); 


log("Exiting"); 


observe0n() 会 在 管道 链 的 某 个 地 方 出 现 ， 但 是 与 subscribeon() 不 同 ，observe0n() 的 
位 置 非常 重要 。 不 管 在 observe0n() 之 前 是 哪个 Scheduler 在 运行 操作 符 (如 果 存 在 
scheduler),， 但 是 在 该 方法 之 后 ， 就 会 由 提供 的 Scheduler 来 运行 所 有 的 工作 。 在 本 例 中 ， 
没有 subscribeon()， 所 以 使 用 默认 的 Scheduler ( 即 没 有 并 发 )， 输 出 如 下 。 
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136 
163 
163 
163 
163 
163 
164 
164 











main | Starting 
main | Created 
main | Subscribed 
main | Found 1: A 
main | Found 1: B 
main | Exiting 


Sched-A-0 | Found 2: A 
Sched-A-0 | Got 1: A 
Sched-A-0 | Found 2: B 


| 塞 用 户 界面 。 但 是 ， 更 新 用 户 界 
有 这 样 的 限制 )， 所 以 我 们 要 在 更 新 UI 的 操 
F 将 (例如 ) Androidschedulers.mainThread() 
8 create() 方法 以 及 第 一 个 























面 的 组 件 必 


门 通过 一 个 
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164 | Sched-A-0 | Got 1: B 
164 | Sched-A-0 | Completed 


observeon 之 前 的 所 有 操作 符 都 是 在 客户 端 线程 中 运行 的 ， 这 正 是 RxJava 的 默认 行为 。 但 


是 在 observe 


时 使 用 subsc 








on() 之 后 ， 所 有 的 操作 符 都 会 在 提供 的 Scheduler 中 和 运行。 如 果 在 管道 中 同 
ribeOn() 和 多 个 observe0n()， 那 么 结果 看 上 去 就 会 更 明显 了 ， 如 下 所 示 。 




















log("Starting"); 
final Observable<String> obs = simple(); 
log("Created"); 


obs 


.do0nNext(x -> log("Found 1: " + x)) 
.observeOn(schedulerB) 
.doOnNext(x -> log("Found 2: " + x)) 
.ObserveOn(schedulerC) 
.do0nNext(x -> log("Found 3: " + x)) 
.SubscribeOn(schedulerA) 
.Subscribe( 
x -> log("Got 1: " + X)， 
Throwable: :printStackTrace, 
() -> log("Completed") 
); 


log("Exiting"); 


你 能 预测 一 


下 输出 吗 ? 注意 ，observe0n() 之 后 的 所 有 代码 都 会 在 提供 的 Scheduler 





中 运行 ， 当 然 ， 这 里 的 所 有 代码 指 的 是 另 一 个 observe0n() 出 现 之 前 的 内 容 。 另 外 ， 





subscribeOn( 


) 可 以 在 Observable 和 subscribe() 之 间 的 任意 位 置 出 现 ， 但 是 此 时 它 只 能 影 

















响 第 一 个 observeon() 出 现 的 位 置 。 输 出 如 下 所 示 。 





21 | main | Starting 

98 | main | Created 

108 | main | Exiting 

129 | Sched-A-0 | Subscribed 
129 | Sched-A-0 | Found 1: A 
129 | Sched-A-0 | Found 1: B 
130 | Sched-B-0 | Found 2: A 
130 | Sched-B-0 | Found 2: B 
130 | Sched-C-0 | Found 3: A 
130 | Sched-C-6 | Got: A 
130 | Sched-C-0 | Found 3: B 
130 | Sched-C-6 | Got: B 
130 | Sched-C-0 | Completed 


订阅 是 在 schedulerA 中 发 生 的 ， 因 为 这 是 在 subscribeon() 中 指定 的 。 同 时 ，Found 1 操 
作 符 也 是 在 该 Scheduler 中 执行 的 ， 因 此 它 出 现在 第 一 个 observeon() 之 前 。 之 后 的 事情 
就 比较 有 意思 了 。observe0n() 将 当前 的 Scheduler 切换 成 了 schedulerB，Found 2 就 会 使 
用 schedulerB 了 。 最 后 一 个 observe0n(schedutLerC) 会 影响 Found 3 操作 符 和 Subscriber。 
需要 记 住 ，Subscriber 会 在 最 后 一 个 Scheduler 的 上 下 文中 执行 。 


























如 果 你 想 物 到 








E 解 看 生产 者 (0bservable.create()) 和 消费 者 (Subscriber) ，subscribeon() 





和 observeOn 


() 能 够 非常 好 地 协作 运行 。 默 认 情 况 下 ， 并 不 存在 这 样 的 结构 ，RxJava 会 使 





用 相同 的 线程 。 仅 有 subscribeon() 并 不 够 ， 借 助 它 只 能 选择 不 同 的 线程 。observe0n() 更 
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好 一 些 ， 但 是 如 果 遇 到 同步 的 0bservabLe， 将 会 导致 客户 端 线程 阻塞 。 大 多 数 操作 符 都 是 
非 阻塞 的 ， 里 面 的 lambda 也 会 非常 简短 ， 执 行 代价 并 不 高 ， 所 以 在 操作 符 管道 中 ， 一 般 
只 使 用 一 个 subscribe0n() 和 Ob eC subscribe0n() 可 以 放 到 接近 原始 Observable 
的 位 置 ， 以 便于 提升 可 读 性 ， 而 observe0n() 应 该 放 到 接近 subscribe() 的 位 置 。 这 样 ， 
只 有 Subscriber 会 使 用 这 个 特殊 的 Scheduler ， 其 他 的 操作 符 则 会 依赖 来 自 subscribeon() 
的 Scheduler。 


如 下 是 一 个 更 高 级 的 程序 ， 它 用 到 了 这 两 个 操作 符 。 


log("Starting"); 
Observable<String> obs = Observable.create(subscriber -> { 
log("Subscribed"); 
subscriber .onNext("A"); 
subscriber .onNext("B"); 
subscriber .onNext("C"); 
subscriber .onNext("D"); 
subscriber .onCompleted(); 




















]); 
log("Created"); 
obs 
.SubscribeOn(schedulerA) 
.flatMap(record -> store(record).subscribeOn(schedulerB)) 
.ObserveOn(schedulerC) 
.SUbscribe( 
x -> log("Got: " + X)， 
Throwable: :printStackTrace, 
() -> log("Completed") 
); 
log("Exiting"); 


其 中 ，store() 是 一 个 简单 的 谍 套 操作 符 。 


Observable<UUID> store(String s) { 
return Observable.create(subscriber -> { 
log("Storing " + s); 
// 这 里 会 有 一 些 繁重 的 工作 
subscriber .onNext(UUID.randomUUID()); 
subscriber .onCompleted(); 





3 
} 


事件 在 schedulerA 中 生成 ,但 是 每 个 事件 都 是 使 用 schedulerB 独立 处 理 的 ， 这 样 能 够 提 
升 并 发 性 ， 这 在 4.9.3 节 介 绍 过 。 而 最 终 的 订阅 却 是 发 生 在 scheduterc 中 的 。 相 信 你 现在 

经 能 够 理解 哪个 scheduler/ 线程 分 别 执行 哪些 操作 了 ， 但 是 以 防 万 一 ， 请 观察 以 下 输出 
(这 里 出 于 清晰 的 考虑 添加 了 空 行 )。 


hol 

















26 | main | Starting 
93 | main | Created 
121 | main | Exiting 


122 | Sched-A-0 | Subscribed 
124 | Sched-B-0 | Storing A 
124 | Sched-B-1 | Storing B 
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124 | Sched-B-2 | Storing C 
124 | Sched-B-3 | Storing D 
1136 | Sched-C-1 | Got: 44b8b999-e687-485f-b17a-al1f6a4bb9ce 
1136 | Sched-C-1 | Got: 532ed720-eb35-4764-844e-690327ac4fe8 
1136 | Sched-C-1 | Got: 13ddf253-c720-48fa-b248-4737579a2c2a 
1136 | Sched-C-1 | Got: Qeced01d-3fa7-45ec-96fb-572ff1ie33587 
1137 | Sched-C-1 | Completed 








对 于 具备 UI 的 应 用 程序 来 说 ，observe0n() 尤为 重要 ， 在 这 样 的 应 用 程序 中 ,我们 不 想 阻 
塞 UI 的 事件 - 分 派 线程 。 在 Android (参见 8.1 节 ) 或 Swing 中 ， 更 新 UI 等 操作 必须 要 
在 特定 的 线程 中 执行 。 但 是 ， 如 果 在 这 个 线程 中 做 太 多 的 事情 ， 将 会 导致 UI 无 法 响应 。 
在 这 种 情况 下 ， 我 们 将 observe0n() 放 在 靠近 subscribe() 的 位 置 ， 以 便 在 特定 Scheduler 
(比如 UI 线程 ) 的 上 下 文中 调用 订阅 中 的 代码 。 而 其 他 的 转换 ， 即 便 执 行 成 本 很 低 ， 也 应 
该 在 UI 线程 之 外 调用 。 在 服务 器 端 很 少 用 observeon() ， 因 为 大 多 数 的 0bservabte 已 经 内 
置 了 并 发 。 这 就 得 出 了 一 个 很 有 意思 的 结论 : RxJava 只 使 用 两 个 操作 符 (subscribeon() 
和 observeon()) 就 控制 了 并 发 ， 但 是 你 使 用 Reactive Extensions 越 频繁 ， 在 生产 代码 中 看 
到 这 两 个 操作 符 的 机 会 就 越 少 。 


4.9.6 ”调度 器 的 其 他 用 途 


很 多 操作 符 默 认 用 到 了 一 些 scheduler。 一 般 情况 下 ， 如 果 不 指定 (JavaDoc 会 详细 说 明 )， 
就 会 使 用 Schedulers.computation()。 例 如 ，delay() 操作 符 接收 上 游 的 事件 ， 并 在 给 定 的 
时 间 之 后 将 这 些 事件 传递 到 下 游 。 显 然 ， 它 不 能 在 等 待 的 时 候 一 直 持 有 原始 的 线程 ， 所 以 
它 必 须要 使 用 一 个 不 同 的 Scheduler。 
Observable 

.just('A', 'B') 

.delay(1, SECONDS, schedulerA) 

.Subscribe(this::10g); 


如 果 不 提 供 自 定义 schedulerA，delay() 后 面 所 有 的 操作 符 都 将 使 用 computation() 
scheduler。 这 本 身 并 没有 什么 问题 。 但 是 ， 如 果 你 的 Subscriber 在 WO 上 被 阻塞 了 ， 那 
么 它 将 会 占用 一 个 来 自 全 局 computation() 调度 器 的 Worker， 这 有 可 能 会 对 整个 系统 产 

影响 。 其 他 支持 自 定义 Scheduler 的 重要 操作 符 有 interval()、range()、timer()、 
repeat()、skip()、take()、timeout()， 还 有 一 些 是 本 书 尚 未 介绍 的 。 如 果 你 不 为 这 些 操 
作 符 提供 调度 器 ， 将 会 使 用 computation() Scheduler， 这 在 大 多 数 情 况 下 是 一 种 安全 的 默 
认 做 法 。 


掌握 调度 器 对 于 编写 可 扩展 和 安全 的 RxJava 代码 至 关 重 要 。 理 解 subscribeon() 和 
observeon() 的 差异 也 是 尤为 重要 的 ， 因 为 在 高 负载 的 场景 中 ， 每 个 任务 都 必须 要 非常 精 
准 地 按照 预期 来 执行 。 在 真正 的 反应 式 应 用 程序 中 ， 所 有 长 期 运行 的 操作 都 是 异步 的 ， 攻 
此 只 需要 很 少 的 线程 和 Scheduler。 但 是 ， 依 然 会 有 API 或 依赖 需要 阻塞 式 的 代码 。 


最 后 ， 但 并 非 不 重要 的 一 点 ， 我 们 必须 要 确保 下 游 使 用 的 Scheduler 能 够 承受 住 上 游 
Scheduler 产生 的 负载 。 这 种 危险 的 场景 会 在 第 6 章 进 行 阐述 。 














































































































4.10 “小结 


本 章 描述 了 在 传统 应 用 程序 中 可 以 替换 为 RxJava 框架 的 一 些 模式 。 和 希望 你 现在 能 够 理解 ， 
高 频率 的 交易 或 者 社交 媒体 上 的 帖子 更 新 并 不 是 RxJava 的 唯一 用 例 。 实 际 上 ， 几 乎 所 有 
的 API 都 可 以 无 颖 替换 为 Observable。 即 便 你 现在 不 想 要 或 者 不 需要 Reactive Extensions 
的 威力 ， 它 也 能 够 在 不 引入 无 法 向 后 兼容 的 变更 的 情况 下 ， 对 你 的 代码 实现 演进 。 另 外 ， 
真正 享受 RxJava 提供 的 各 种 可 能 性 的 是 客户 端 ， 比 如 延迟 执行 、 声 明 式 并 发 和 异步 链 。 
更 棒 的 是 ， 由 于 0bservable 到 BlockingObservable 的 无 颖 转换 ， 传 统 客户 端 可 以 按照 它们 
的 需要 消费 API， 你 可 以 一 直 提 供 一 个 简单 的 桥接 层 。 

你 应 该 对 RxJava 非常 有 信心 了 ， 并 且 已 经 理解 在 遗留 系统 中 使 用 它 会 带 来 的 收益 。 毫 
无 疑问 ， 使 用 反应 式 Observable 更 具 挑 战 性 ， 在 一 定 程度 上 它 的 学 习 曲 线 也 很 陡峭 。 但 
是 ， 也 不 能 一 味 夸 大 它 的 优势 和 面 对 系 统 增长 时 的 可 能 性 。 设 想 一 下 ， 如 果 使 用 Reactive 
Extensions 从 头 到 尾 实现 一 个 完整 的 应 用 程序 ， 又 会 怎样 ?就 像 一 个 绩 新 的 项 目 ， 我 们 可 
以 控制 每 个 API、 接 口 和 外 部 系统 。 第 5 章 将 会 讨论 如 何 编 写 这 种 应 用 程序 ， 以 及 这 样 的 
应 用 程序 意味 着 什么 。 
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第 5 章 


实现 完整 的 反应 式 应 用 程序 





托 马 什 : 努 尔 凯 维 茨 〈Tomasz Nurkiewicz) 





在 RxJava 之 禅 中 ， 经 常 提 到 的 一 句 话 就 是 “万 物 皆 是 流 ”。 第 4 章 介绍 了 如 何 将 RxJava 应 
用 到 已 有 的 代码 库 中 。 但 是 ， 我 们 很 快 发 现 ， 真 正 的 反应 式 应 用 程序 大 多 都 从 头 到 尾 使 用 
流 。 这 种 方式 能 够 简化 对 系统 的 理解 ， 并 且 保 证 应 用 程序 高 度 一 致 。 非 阻塞 应 用 程序 借助 
少量 的 硬件 就 能 提供 很 好 的 性 能 和 吞吐 量 。 通 过 限制 线程 的 数量 ， 我 们 能 够 充分 利用 CPU 
资源 ， 而 不 会 消耗 千 焰 字 节 的 内 存 。 


在 Java 中 ， 扩 展 性 的 一 个 限制 就 是 其 VO 机 制 。java.io 包 设 计 得 非常 好 ， 包 含 了 很 多 小 
型 的 Input/0utputStream 和 Reader/Writer 实现 ， 它 们 互相 修饰 和 包装 ， 每 次 只 添加 一 项 功 
能 。 尽 管 我 非常 喜欢 这 种 优雅 的 关注 点 分 离 ， 但 是 在 Java 中 标准 IO 完全 是 阻塞 的 ， 这 意 
味 着 每 个 想 通过 Socket 或 File 进行 读 取 和 写 入 的 线程 必须 无 限期 地 等 竺 结果。 更 糟糕 的 
是 ， 由 于 网 络 速度 或 磁盘 旋转 速度 缓慢 ， 线 程 卡 顿 在 IO 操作 中 很 难 中 断 。 阻 塞 本 身 不 是 
问题 ， 一 个 线程 被 阻塞 时 ， 其 他 线程 仍然 可 以 与 其 他 打开 的 Socket 交互 。 但 是 创建 和 管理 
线程 的 成 本 很 高 昂 ， 而 且 线 程 之 间 的 切换 也 需要 时 间 。Java 应 用 程序 完全 能 够 处 理 数 万 个 
并 发 连接 ， 但 必须 非常 仔细 地 进行 设计 。RxJava 与 一 些 事 件 驱动 的 现代 库 协 作 时 ， 这 种 设 
计 工 作 就 能 大 幅 减 少 。 


5.1 解决 C10k 问 题 
C10k 问题 是 一 个 研究 和 优化 的 领域 ， 它 尝试 在 单个 商用 服务 器 上 实现 10 000 个 并 发 连接 。 


即便 是 现在 ， 使 用 传统 的 Java 工具 集 完成 这 一 工程 任务 也 是 颇 有 挑战 性 的 。 有 很 多 反应 
式 的 方式 ,借助 它们 能 够 很 容易 达成 C10k， 而 借助 RxJava， 能 够 让 这 些 方式 更 具 可 行 性 。 
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本 章 将 会 探索 几 种 实现 技术 ， 它 们 能 够 将 扩展 性 提升 几 个 数量 级 。 这 些 技术 都 是 围绕 反应 

式 编程 的 理念 构建 的 。 如 果 你 非常 幸运 ， 能 够 从 头 开始 一 个 项 目 ， 那 么 可 能 会 考虑 将 这 个 

项 目 完全 以 反应 式 的 方式 来 实现 。 这 样 的 应 用 程序 永远 不 会 同步 地 等 待 计算 或 其 他 操作 完 

成 。 为 了 避免 阻 寨 , 架构 必须 全 部 是 事件 驱动 和 异步 的 。 本 节 将 会 介绍 几 个 简单 的 HTTP 

服务 器 样 例 ， 并 观察 基 于 我 们 的 各 种 设计 决策 ， 它 会 有 什么 样 的 行为 。 不 得 不 承认 ， 性 能 

和 可 扩展 性 确实 非常 复杂 。 但 是 ， 借 助 RxJava， 这 些 额 外 的 复杂 性 将 会 大 幅度 降低 。 

每 个 连接 对 应 的 经 典 线程 模型 都 在 努力 解决 C10k 问题 。 如 果 有 10 000 个 线程 ， 那 么 将 会 

面临 如 下 情况 。 

。 为 了 存储 栈 空 间 ， 消 耗 数 个 千 兆 字 节 的 RAM。 

。 给 垃圾 收集 机 制 带 来 巨大 的 压力 ， 不 过 栈 空间 是 不 能 进行 垃圾 收集 的 (大 量 的 GC 根 和 
存活 对 象 ) 。 

。 浪费 大 量 的 CPU 时 间 只 是 用 于 切换 核心 以 运行 各 种 线程 (上下文 切换 )。 


在 有 些 场景 中 ， 经 典 的 线程 -Socket (thread-per-Socket) 模型 能 够 很 好 地 满足 要 求 ， 事 实 
上 ， 直 到 今天 它 在 很 多 应 用 程序 上 都 运行 得 非常 好 。 但 是 ， 在 达到 一 定 级 别 的 并 发 之 后 ， 
线程 的 数量 就 会 变 得 非常 危险 。 由 单个 商用 服务 器 处 理 1000 个 并 发 连接 的 情况 并 不 罕见 ， 
在 长 期 存活 的 TCP/IP 连接 场景 中 更 是 如 此 ， 比 如 带 有 Keep-Alive 头 信息 的 HITP、 服 务 
器 发 送 事 件 (server-sent event) 和 WebSocket。 但 是 ， 不 管线 程 正在 进行 计算 还 是 等 待 数 
据 的 到 达 ， 每 个 线程 都 会 占据 一 些 内 存 〈 栈 空间 ) 。 


在 实现 扩展 性 方面 ， 有 两 种 相互 独立 的 方式 : 水 平 扩展 和 垂直 扩展 。 为 了 处 理 更 多 的 并 发 
连接 ， 我 们 可 以 部 署 更 多 的 服务 器 ， 每 个 服务 器 管理 负载 的 一 个 子 集 。 这 需要 一 个 前 端 
的 负载 均衡 器 ， 但 是 这 样 的 方式 也 没有 解决 最 初 的 C10k 问题 ， 即 仅 用 一 台 服 务 器 处 理 负 
载 。 而 另 一 方面 ， 垂 直 扩展 意味 着 要 购买 更 大 更 强 的 服务 器 。 但 是 ， 由 于 阻塞 式 IJO， 与 
未 充分 利用 的 CPU 相 比 ， 需 要 与 之 不 相称 的 内 存 占用 。 即 便 大 型 的 企业 服务 器 能 够 处 理 
数 十 万 个 并 发 连接 (价格 非常 高 郧 )， 但 是 它 却 远 远 不 能 解决 C10M 的 问题 ， 也 就 是 1000 
万 个 并 发 连接 。 这 个 数字 并 非 巧 合 ， 数 年 之 前 ， 在 一 台 典 型 的 服务 器 上 ， 一 个 经 过 精心 设 
计 的 Java 应 用 程序 就 达到 了 如 此 惊人 的 水 准 。 

本 章 将 会 介绍 实现 HTTP 服务 器 的 各 种 方式 。 从 单线 程 服务 器 ， 到 线程 地 ， 再 到 完全 事件 
驱动 的 架构 。 这 种 练习 背后 的 理念 是 对 比 实现 的 复杂 度 、 性 能 和 吞吐 量 。 最 后 ， 你 将 会 发 
现 ， 使 用 RxJava 的 版 本 相对 简洁 ， 性 能 也 非常 出 色 。 


5.1.1 传统 的 基于 线程 的 HTTP 服 务 器 

本 节 将 会 对 比 阻塞 式 服务 器 〈 即 便 编 写 得 非常 好 ) 在 高 负载 情况 下 的 表现 。 我 们 可 能 都 做 
过 这 个 练习 : 基于 原始 Socket 编写 一 个 服务 器 。 接 下 来 ， 本 节 将 会 编写 一 个 简单 的 HITP 
服务 器 ， 它 会 对 每 个 请 求 都 响应 200 OK。 实 际 上 ， 为 了 简洁 ， 样 例会 完全 忽略 这 个 请 求 
的 内 容 。 

单线 程 的 服务 器 

最 简单 的 实现 就 是 打开 一 个 serversocket， 并 在 客户 端 连接 到 达 之 时 对 其 进行 处 理 。 处 理 
某 个 请 求 时 ， 其 他 的 请 求 都 要 排队 。 如 下 的 代码 片段 实际 上 非常 简单 。 
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class SingleThread { 


public static final byte[] RESPONSE = (人 
"HTTP/1.1 200 OK\r\n" + 
"Content-Length: 2\r\n" + 
"\r\n" + 
"OK") .getBytes(); 


public static void main(String[] args) throws IOException { 
final ServerSocket serverSocket = new ServerSocket(8080, 100); 
while (!Thread.currentThread().isInterrupted()) { 
final Socket client = serverSocket.accept(); 
handle(client); 


} 


private static void handle(Socket client) { 


try { 
while (!Thread.currentThread().isInterrupted()) { 


readFullRequest(client); 
client.getOutputStream().write(RESPONSE); 


} 

} catch (Exception e) { 
e.printStackTrace(); 
IOUtils.closeQuietly(client); 


} 


private static void readFullRequest(Socket client) throws IOException { 
BufferedReader reader = new BufferedReader( 
new InputStreamReader(client.getInputStream())); 
String Line = reader.readLine(); 
while (line != null && !line.isEmpty()) { 
Line = reader.readLine(); 


} 


} 


除了 在 大 学 里 ， 你 可 能 看 不 到 类 似 的 底层 实现 ， 但 是 它 确实 能 够 运行 。 对 于 每 个 请 
求 ， 样 例 忽 略 它 实际 发 送 的 内 容 ， 而 是 直接 返回 200 OK 的 响应 。 在 浏览 器 中 打开 
Localhost:8080， 你 将 会 看 到 OK 文本 的 成 功 响 应 。 这 也 是 该 类 被 称 为 singleThread 的 原 
因 。serverSocket .accept() 会 一 直 阻 塞 ， 直 到 与 某 个 客户 端 建立 连接 为 止 。 然 后 ， 它 返回 
一 个 客户 端 Socket。 与 这 个 Socket 进行 交互 ( 读 取 或 写 和 信 ) 时 ， 样 例 依 旧 还 在 监听 传 入 
的 连接 ， 但 是 这 些 连 接 不 会 得 到 处 到 为 线程 正 忙 于 处 理 第 一 个 客户 端 。 这 就 像 医 生 的 
诊室 一 样 : 一 个 病人 进入 就 诊 时 ， 其 他 的 病人 只 能 排队 等 待 。 注 意 到 8089 参数 〈 监 听 端 
口 ) 后 面 还 有 一 个 额外 的 参数 109 了 吗 ? 这 个 值 (默认 值 为 56) 限制 了 在 队列 中 可 以 等 待 
的 挂 起 连接 的 数量 。 如 果 超 过 这 个 值 ， 连 接 就 会 被 拒绝 。 更 糟糕 的 是 ， 我 们 在 这 里 假定 实 
现 的 是 HTTP/1.1， 它 默认 使 用 持久 化 连接 。 在 客户 端 连接 关闭 之 前 ， 样 例会 保持 TCP/IP 
连接 处 于 打开 状态 ， 这 会 阻塞 新 的 客户 端 。 
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现在 ， 回 到 客户 端 连接 上 ， 首 先 读 取 整个 请 求 ， 然 后 写 入 响应 。 这 两 个 操作 可 能 都 会 阻 
塞 ， 并 受 网 络 缓慢 或 拥堵 的 影响 。 如 果 某 个 客户 端 建立 了 连接 ， 但 是 等 待 了 几 秒 之 后 才 发 
送 请 求 ， 那 么 其 他 的 客户 端 必须 要 等 待 。 让 一 个 线程 来 处 理 所 有 的 传 入 连接 显然 不 具备 扩 
展 性 ， 我 们 仅仅 解决 了 C1 (一 个 并 发 连接 ) 问题 。 

附录 A 包含 了 源 代 码 ， 以 及 关于 其 他 阻塞 式 服务 器 的 讨论 。 本 章 不 再 花费 更 多 的 时 间 分 析 
非 扩展 性 的 阻塞 式 架构 ， 而 是 对 它们 进行 简要 地 总 结 ， 这 样 ， 就 能 对 它们 进行 快速 的 基准 
测试 和 统一 的 对 比 。 
在 A.l 节 ， 你 将 会 看 到 使 用 C 语言 的 fork() 编写 的 简单 服务 器 的 源 代码 。 尽 管 看 上 去 非 
党 简单， 但 是 它 为 每 个 新 的 客户 端 连接 均 建 立 了 一 个 新 的 进程 ， 这 样 会 给 操作 系统 带 来 很 
沉重 的 负载 ， 对 于 存活 时 间 非 常 短 的 连接 来 说 ， 情 况 会 更 加 严重 。 每 个 进程 都 需要 很 多 内 
存 而 且 初 始 化 过 程 会 消耗 一 定 的 时 间 。 另 外 ， 上 千 个 进程 的 启动 或 停止 总 是 会 不 必要 地 占 
用 系统 资源 。 

ThreadPerConnection (参见 A.2 节 ) 展示 了 如 何 实现 阻塞 式 服务 器 ， 它 为 每 个 客户 端 连 接 
都 创建 了 一 个 新 线程 。 它 的 扩展 性 可 能 不 错 ， 但 是 会 遇 到 与 C 语言 中 的 fork() 同样 的 问 
题 ， 启动 一 个 新 的 线程 会 消耗 一 定 的 时 间 和 资源 。 对 于 短期 存活 的 连接 来 说 ， 这 显得 尤其 
浪费 。 除 此 之 外 ， 可 同时 运行 的 客户 端 线程 并 没有 最 大 数量 的 限制 。 在 计算 机 系统 中 ， 如 
果 你 不 对 某 个 事情 进行 限制 ， 问 题 将 会 以 最 糟糕 的 方式 在 你 最 不 期 望 的 地 方 出 现 。 例 如 ， 
如 果 出 现 上 千 的 并 发 连接 ， 程 序 将 会 变 得 不 稳定 ， 并 且 最 终 会 因 0utofMemoryError 而 
崩溃 。 

ThreadPool (参见 A.3 节 ) 同样 也 会 为 每 个 连接 建立 一 个 线程 ， 但 是 客户 端 断 开 连接 时 ， 
线程 会 被 回收 ， 这 样 ， 就 节省 了 为 每 个 客户 端 预 热线 程 的 成 本 。 这 与 流行 的 Servlet 容器 
(如 Tomcat 和 Jetty) 的 运行 方式 非常 类 似 ， 它 们 会 默认 在 池 中 维持 100 到 200 个 线程 。 
Tomcat 有 所 谓 的 NIO 连接 器 ， 会 以 异步 的 方式 处 理 Socket 上 一 些 操作 ， 但 是 Servlet 以 及 
基于 Servlet 构建 的 框架 依然 会 以 阻塞 式 的 方式 运行 。 这 意味 着 传统 的 应 用 程序 即便 使 用 现 
代 化 的 Servlet 容器 ， 最 多 也 只 能 有 数 千 个 连接 。 


5.1.2 借助 Netty 和 RxNetty 实 现 非 阻塞 的 HTTP 服 务 器 


现在 ， 关 注 一 下 使 用 事件 驱动 的 方式 来 编写 HTTP 服务 器 ， 这 种 方式 在 扩展 性 方面 更 值得 
期 待 。 在 阻塞 式 的 处 理 模 型 中 ， 每 个 请 求 对 应 一 个 线程 显然 无 法 进行 扩展 。 我 们 需要 一 种 
仅 用 少量 线程 就 能 管理 大 量 客户 端 连接 的 方式 。 这 种 方式 具有 如 下 优点 。 

。 减少 内 存 消耗 。 
。 更 好 的 CPU 和 CPU 缓存 利用 率 。 

。 在 单个 节点 上 极 大 地 提升 可 扩展 性 。 

但 是 这 种 方式 会 以 失去 简洁 性 和 清晰 性 为 代价 。 线 程 不 允许 在 任何 操作 上 阻塞 ,我 们 不 能 
再 假设 通过 线路 接收 或 发 送 数据 的 线程 与 执行 本 地 方法 调用 的 线程 相同 。 延 迟 是 难以 预测 
的 ， 而 响应 时 间 也 会 高 儿 个 数量 级 。 到 你 阅读 本 书 的 时 候 ， 可 能 还 有 很 多 旋转 磁盘 驱动 
器 ， 它 们 甚至 比 局 域 网 还 要 慢 。 本 节 将 会 使 用 Netty 框架 开发 一 个 小 型 的 事件 驱动 应 用 程 
序 ， 随 后 将 其 重 构 为 RxNetty。 最 后 ， 本 节 会 对 所 有 的 方案 进行 基准 测试 。 
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Netty 完全 是 事件 驱动 的 ， 不 必 阻 塞 等 待 数 据 发 送 或 接收 。 相 反 ， 原 始 字 市 会 以 ByteBuf 实 
例 的 形式 推送 到 处 理 管道 中 。TCP/P 给 人 的 印象 是 连接 和 数据 会 在 两 台 计 算 机 之 间 一 个 字 
市 接 一 个 字 节 地 流动 。 但 事实 上 ，TCP/IP 是 构建 在 IP 上 的 ，IP 几乎 不 能 传递 块 状 的 数据 ， 
也 就 是 packet。 操 作 系 统 负责 按照 正确 的 顺序 组 装 它们 ， 并 制造 一 种 流 的 假象 。Netty 放 
弃 了 这 种 抽象 ， 它 在 字 布 序列 层 运行 ， 而 不 是 在 流 的 层面 。 字 节 到 达 应 用 程序 时 ，Netty 
就 会 通知 处 理 器 。 发 送 字 节 时 ， 会 得 到 一 个 没有 阻塞 的 ChanneLFuture (关于 future 的 更 多 
内 容 会 在 后 文 阐述 )。 
我 们 的 非 阻塞 HTTP 服务 器 有 三 个 组 件 。 第 一 个 组 件 会 启动 服务 器 并 搭建 环境 ， 如 下 所 示 。 
import io.netty.bootstrap.ServerBootstrap; 
import io.netty.channel.*; 


import io.netty.channel.nio.NioEventLoopGroup; 
import io.netty.channel.socket.nio.NioServerSocketChannel; 





















































class HttpTcpNettyServer { 


public static void main(String[] args) throws Exception { 
EventLoopGroup bossGroup = new NioEventLoopGroup(1); 
EventLoopGroup workerGroup = new NioEventLoopGroup(); 


try { 
new ServerBootstrap() 
.option(ChannelOption.SO_BACKLOG, 50_000) 
.group(bossGroup, workerGroup) 
.Channel(NioServerSocketChannel.class) 
.ChildHandler(new HttpInitializer()) 
.bind(8080) 
.sync() 
.channel() 
.CloseFuture() 
.sync(); 
} finally { 
bossGroup.shutdownGracefully(); 
workerGroup.shutdownGracefully(); 


} 


这 是 使 用 Netty 编写 的 最 基础 的 HTTP 服务 器 。 核 心 部 分 是 负责 接收 传 入 连接 的 bossGroup 
池 和 处 理事 件 的 workerGroup。 这 些 池 都 不 大 : bossGroup 大 小 为 1!， 而 workerGroup 则 
应 该 接近 CPU 核心 的 数量 。 对 于 编写 良好 的 Netty 服务 器 来 说 ， 这 已 经 足够 了 。 在 这 
里 ， 除 了 监听 8080 端口 之 外 ， 我 们 还 没有 指定 服务 器 应 该 做 什么 。 有 具体 做 什么 可 以 通过 
ChannelInitializer 来 配置 ， 如 下 所 示 。 

import io.netty.channel.ChannelInitializer; 


import io.netty.channel.socket.SocketChannel; 
import io.netty.handler.codec.http.HttpServerCodec; 





























class HttpInitializer extends ChannelInitializer<SocketChannel> { 


private final HttpHandler httpHandler = new HttpHandler(); 
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@Override 
public void initChannel(SocketChannel ch) { 
ch 
.pipeline() 
.addLast(new HttpServerCodec()) 
.addLast(httpHandler); 


} 


这 里 并 不 是 提供 了 一 个 处 理 连接 的 函数 ， 而 是 构建 了 一 个 管道 ， 处 理 传人 的 ByteBuf 实例 。 
这 个 管道 的 第 一 步 是 将 传 入 的 原始 字 节 解码 为 更 高 层级 的 HTTP 请 求 对 象 。 这 个 处 理 器 是 


内 置 的 。 它 还 能 够 将 HTTP 响应 编码 为 原始 字 闻 。 在 更 为 健 由 











As 


的 应 用 程序 中 ， 你 通常 会 


到 更 多 的 处 理 器 聚焦 在 更 小 的 功能 上 ， 例 如 ， 帧 解码 、 协 议 解 码 、 安 全 性 等 。 每 段 数据 和 


通知 都 会 流 经 该 管道 。 


你 可 能 





已 经 看 到 与 RxJava 类 似 的 地 方 了 。 管 道 的 第 二 步 是 业务 逻辑 组 件 ， 它 会 实际 处 理 





请 求 ， 而 不 仅仅 是 对 其 进行 拦截 或 增强 。 尽 管 HttpserverCodec 在 本 质 上 是 有 状态 的 ( 它 
将 传人 的 包 转 换 成 了 更 高 层级 的 HttpRequest 实例 )， 但 是 自 定义 的 HttpHandler 可 以 是 一 
个 无 状态 的 单 例 类 。 


import io.netty.channel.*; 
import io.netty.handler.codec.http.*; 


@Sharable 
class HttpHandler extends ChannelInboundHandlerAdapter { 


@Override 

public void channelReadComplete(ChannelHandlerContext ctx) { 
ctx.flush(); 

} 


@Override 
public void channelRead(ChannelHandlerContext ctx, Object msg) { 
if (msg instanceof HttpRequest) { 
sendResponse(ctx); 
} 
} 


private void sendResponse(ChanneLHandLerContext ctx) { 
final DefaultFullHttpResponse response = new DefauLtFuULLHttpResponse( 
HTTP_1_1, 
HttpResponseStatus .OK ， 
UnpooLed.wrappedBuffer("OK" .getBytes(UTF_8) )); 
response.headers().add("Content-length", 2); 
ctx.writeAndFlush(response); 


} 


@Override 

public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) { 
log.error("Error", cause); 
ctx.close(); 
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在 构建 完 响 应 对 象 之 后 ， 样 例 通 st 将 和 写 回 。 但 是 ， 




















write() 与 常规 的 socket 并 不 相同 ， 它 并 不 会 阻塞 。 相 反 ， 它 会 返回 一 个 ChanneLFuture， 
我 们 可 以 通过 addListener() 对 其 进行 订阅 并 异步 关闭 通道 如 下 所 示 。 
ctx 


.writeAndFlush(response) 
.addListener(ChannelFutureListener .CLOSE); 


通道 (channel) 是 对 通信 连接 的 抽象 ， 例 如 HTTP 连接 ， 因 此 关闭 通道 就 会 关闭 连接 。 为 
了 实现 持久 化 连接 ， 我 们 不 希望 这 样 做 。 


Netty 只 用 届 指 可 数 的 线程 就 能 处 理 上 百 个 连接 。 我 们 没有 为 每 个 连接 保留 任何 重量 级 的 
数据 结构 或 线程 ， 这 与 本 质 更 加 接近 。 计 算 机 接收 到 一 个 IP 包 ， 并 唤醒 监听 该 目标 端口 的 
进程 。TCP/IP 连接 通常 会 使 用 线程 来 实现 抽象 ， 但 是 ， 如 果 应 用 程序 需要 更 高 的 负载 和 连 
接 数 ， 直 接 在 包 级 别 进行 操作 会 更 加 可 靠 。 我 们 依然 会 有 通道 (线程 的 轻 量 级 表述 ) 和 管 
道 的 概念 ， 以 及 可 能 会 有 状态 的 处 理 器 。 


使 用 RxNetty 实 现 Observable 服 务 器 
Netty 是 很 多 成 功 产 品 和 框架 的 重要 支撑 ， 比 如 Akka、Elasticsearch、HornetQ、Play 框架 
Ratpack 和 Vert.x。 围 绕 Netty 也 有 很 薄 的 一 层 抽 象 ， 通 过 这 层 抽象 能 够 将 Netty API 和 
RxJava 连接 在 一 起 。 接 下 来 ， 让 我 们 使 用 RxNetty 重 写 非 阻塞 的 Netty 服务 器 。 先 从 一 个 
简单 的 货币 服务 器 入 手 来 熟悉 API， 如 下 所 示 。 

import io.netty.handler.codec.LineBasedFrameDecoder; 


import io.netty.handler.codec.string.StringDecoder; 
import io.reactivex.netty.protocol.tcp.server.TcpServer; 













































































class EurUsdCurrencyTcpServer { 
private static final BigDecimal RATE = new BigDecimal("1.06448"); 


public static void main(final String[] args) { 
TcpServer 

.NewServer(8080) 

.<String, String>pipelineConfigurator(pipeline -> { 
pipeline.addLast(new LineBasedFrameDecoder(1024)); 
pipeline.addLast(new StringDecoder(UTF_8) ); 

}) 

.Start(connection -> { 

Observable<String> output = connection 
.getInput() 
.map(BigDecimal: :new) 
.flatMap(eur -> eurToUsd(eur)); 
return connection.writeAndFlushOnEach(output); 
}) 
.awaitShutdown(); 


3 


static Observable<String> eurToUsd(BigDecimal eur) { 
return Observable 
.just(eur.multiply(RATE)) 
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.map(amount -> eur + " EUR is " + amount + " USD\n") 
.delay(1, TimeUnit.SECONDS); 
} 
} 


这 是 一 个 基于 RxNetty 编写 的 自给 自足 的 TCP/P 服务 器 。 你 应 该 对 它 的 主要 组 成 部 分 有 
一 个 大 致 的 了 解 。 首 先 ， 我 们 创建 了 一 个 新 的 TCP/IP 服务 器 来 监听 8080 端口 。Netty 为 
流 经 管道 的 ByteBuf 消息 提供 了 非常 低层 级 的 抽象 。 样 例 必须 要 配置 这 样 的 管道 。 第 一 个 
处 理 器 会 使 用 内 置 的 LineBasedFrameDecoder 将 ByteBuf 序列 重新 排列 ( 按 需 进行 拆 分 和 连 
接 ) 为 行 数据 的 序列 。 随 后 ， 解 码 器 会 将 包含 所 有 数据 行 的 ByteBuf 转换 为 String 实例 。 
从 此 处 开始 ， 就 可 以 只 处 理 String 了 。 


每 次 新 的 连接 到 达 ， 回 调 就 会 执行 。Connection 对 象 允 许 异 步 发 送 和 接收 数据 。 首 先 从 
connection.getInput() 开始 。 这 个 对 象 是 0bservabLe<String> 类 型 的 ， 每 次 客户 端 新 的 一 
行 请 求 在 服务 器 出 现 ， 它 就 会 发 布 一 个 值 。getInput()0bservablte 会 以 异步 的 方式 通知 新 
的 输入 。 首 先 将 String 解析 为 BigDecimal， 然 后 使 用 辅助 方法 eurTousd()， 假 装 调 出 一 
些 货币 兑换 服务 。 为 了 让 这 个 样 例 看 上 去 更 加 真实 ， 我 们 还 人 为 地 应 用 了 delay()， 这 样 ， 
必须 等 待 一 会 儿 才 能 得 到 响应 。 显 然 ，delay() 是 异步 的 ， 不 会 涉及 任何 的 休眠 。 与 此 同 
时 ， 我 们 会 不 断 地 接收 和 转换 请 求 。 


在 将 所 有 的 转换 完成 后 ，output Observable 会 直接 输入 到 writeAndFLushOnEach() 方法 。 
这 些 内 容 很 容易 理解 ， 接 收 一 个 输入 序列 ， 对 它们 进行 转换 ， 然 后 将 转换 后 的 序列 作为 输 
出 。 现 在 ， 使 用 telnet 与 服务 器 进行 交互 。 请 注意 一 下 ， 有 些 响应 是 在 消费 多 个 请 求 之 后 
才 出 现 的 ， 这 是 伪造 的 货币 服务 器 存在 延迟 的 缘故 。 


$ telnet localhost 8080 
Trying 127.0.0.1... 
Connected to localhost. 
Escape character is '^]'. 
2.5 

2.5 EUR is 2.661200 USD 
0.99 

0.99 EUR is 1.0538352 USD 
0.94 

0.94 EUR is 1.0006112 USD 






























































20 EUR is 21.28960 USD 
30 EUR is 31.93440 USD 
40 EUR is 42.57920 USD 


服务 器 被 视 为 将 请 求 数据 转换 为 响应 数据 的 函数 。 因 为 TCP/PP 不 仅仅 是 一 个 简单 的 函数 ， 
有 时 候 还 是 由 相互 依赖 的 数据 块 组 成 的 流 ， 在 这 种 场景 下 RxJava 运行 得 也 非常 好 。 借 助 
一 组 非常 丰富 的 操作 符 ， 能 够 很 容易 地 将 输入 转换 为 输出 。 当 然 ， 输 出 流 并 不 一 定 是 要 基 
于 输入 的 。 例 如 ， 如 果 你 实现 服务 器 端 推送 事件 ， 服 务 器 端 只 是 发 布 数据 而 已 ， 与 传 入 的 
数据 并 没有 关联 。 

EurUsdCurrencyTcpServer 是 反应 式 的 ， 因 为 只 有 数据 传人 的 时 候 ， 它 才 会 采取 相应 的 行 









































实现 完整 的 反应 式 应 用 程序 | 141 











为 。 对 于 每 个 客户 端 ， 我 们 不 会 为 其 创建 单独 的 线程 。 这 种 实现 方式 可 以 很 容易 地 承担 数 
千 个 并 发 连接 ， 而 且 垂直 可 扩展 性 仅 会 受到 必须 要 处 理 的 通信 量 的 限制 ， 而 不 会 受到 或 多 
或 少 空闲 连接 数量 的 限制 。 


现在 ， 我 们 已 经 知道 了 RxNetty 的 工作 原理 ， 接 下 来 可 以 回 到 返回 OK 响应 的 原始 HTTP 服 
务 器 。RxNetty 内 置 了 对 HITP 客户 端 和 服务 器 端的 支持 ， 但 是 我 们 将 从 基于 TCP/P 的 简 
单 实现 开始 进行 讲解 。 

import io.netty.handler.codec.LineBasedFrameDecoder; 

import io.netty.handler.codec.string.StringDecoder; 


import io.reactivex.netty.examples.AbstractServerExample; 
import io.reactivex.netty.protocol.tcp.server.TcpServer; 

































































import static java.nio.charset.StandardCharsets.UTF_8; 
class HttpTcpRxNettyServer { 


public static final Observable<String> RESPONSE = Observable.just( 
"HTTP/1.1 200 OK\r\n" + 
"Content-Length: 2\r\n" + 
"\r\n" + 
"OK"); 


public static void main(final String[] args) { 
TcpServer 

.NewServer(8080) 

.<String, String>pipelineConfigurator(pipeline -> { 
pipeline.addLast(new LineBasedFrameDecoder(128)); 
pipeline.addLast(new StringDecoder (UTF_8)); 

}) 

.Start(connection -> { 

Observable<String> output = connection 
.getInput() 
.flatMap(line -> { 
if (line.isEmpty()) { 
return RESPONSE; 
} elsef{ 
return Observable.empty(); 


} 
]); 
return connection.writeAndFlushOnEach(output); 
}) 
.awaitShutdown(); 


} 





掌握 了 EurUsdCurrencyTcpServer 之 后 ， 再 去 理解 HttpTcpRxNettyServer 就 应 该 非常 容 
易 了 。 出 于 教学 的 目的 ， 样 例 始终 返回 静态 的 209 Ok 响应 ， 在 这 里 解析 请 求 没有 太 大 
的 意义 。 但 是 ， 设 计 良 好 的 服务 器 在 读 取 请 求 之 前 是 不 应 该 发 送 响应 的 。 因 此 ， 首 先 在 
getInput() 中 查找 一 个 空 行 ， 它 代表 了 HTTP 请 求 的 结束 。 在 此 之 后 ， 才 生成 200 ok 的 响 
应 行 。 按 照 这 种 方式 构建 的 output 0bservable 会 被 传递 给 connection.writeString()。 换 
名 话说 ， 一 旦 遇 到 请 求 包含 空 行 的 场景 ， 响 应 将 会 立即 发 送 给 客户 端 。 
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使 用 TCP/IP 来 实现 HTTP 服务 器 只 是 一 个 练习 而 已 ， 它 能 够 帮助 你 理解 HITP 的 复杂 之 


处 。 幸 好 我 们 不 必 每 次 都 使 用 TCP/IP 抽象 来 实现 HITP 和 RESTful Web 服务 。 与 Netty 类 
似 ，RxNetty 也 有 一 些 用 于 HTTP 功能 的 内 置 组 件 ， 如 下 所 示 。 


import io.reactivex.netty.protocol.http.server.HttpServer; 


class RxNettyHttpServer { 


private static final Observable<String> RESPONSE_OK = 
Observable.just("0OK"); 


public static void main(String[] args) { 
HttpServer 
.NewServer(8086) 
.start((req, resp) -> 
resp 
.SetHeader (CONTENT_LENGTH, 2) 


.WriteStringAndFLushOnEach(RESPONSE_OK) 
) .awaitShutdown(); 


} 


如 果 你 厌倦 了 只 返回 静态 的 200 OK， 那么 我 们 可 以 相对 轻松 地 构建 非 阻塞 的 RESTful Web 
服务 ， 同 样 适用 于 实现 货币 交换 功能 。 


class RestCurrencyServer { 





private static final BigDecimal RATE = new BigDecimal("1.06448"); 


public static void main(final String[] args) { 
HttpServer 
.NewServer(8080) 
.Start((req, resp) -> { 
String amountStr = req.getDecodedpath().substring(1); 
BigDecimal amount = new BigDecimal(amountStr); 
Observable<String> response = Observable 


.just(amount) 
.map(eur -> eur.multiply(RATE)) 
.map(usd -> 
"{\"EUR\": "+ amount + ", "+ 
"\"USD\": mh 机 Usd 证 es 
return resp.writeString(response); 
}) 
.awaitShutdown(); 


} 


可 以 使 用 Web 浏览 器 或 curt 与 这 个 服务 器 进行 交互 。 为 了 去 除 请 求 中 的 第 一 条 和 斜 线 ， 这 
里 用 到 了 substring(1) 。 


$ curl -v localhost:8080/10.99 


> GET /10.99 HTTP/1.1 
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> User-Agent: curl/7.35.0 
> Host: LocaLhost:8080 

> Accept: */* 

> 


< HTTP/1.1 200 OK 
< transfer-encoding: chunked 
< 


{"EUR": 10.99, "USD": 11.6986352} 


现在 有 了 这 个 简单 HTTP 服务 器 的 多 个 实现 ， 我 们 可 以 对 比 它 们 的 性 能 、 可 扩展 性 和 吞吐 
量 。 这 也 是 放弃 熟悉 的 基于 线程 的 模型 ， 转 而 着 手 使 用 RxJava 和 异步 API 的 原因 。 


5.1.3 阻塞 式 和 反应 式 服 务 器 的 基准 测试 


为 了 阐述 非 阻 塞 、 反 应 式 HTTP 服务 器 的 价值 和 成 功 的 原因 ， 本 节 将 为 每 种 实现 方式 运行 
一 系列 基准 测试 。 有 意思 的 是 ， 我 们 选择 的 基准 测试 工具 wrk 也 是 非 阻塞 的 。 否 则 ， 它 本 
身 无 法 模拟 数 万 个 并 发 连接 的 负载 。 另 外 一 个 可 选 的 工具 是 Gatling， 它 构建 在 Akka 工具 
集 之 上 。 传 统 的 基于 线程 的 工具 无 法 模拟 这 种 大 量 的 负载 ， 如 JMeter 和 ab， 它们 本 身 就 
会 成 为 瓶颈 。 
每 个 基于 JVM 的 实现 ! 都 会 针对 10 000、20 000 和 50 000 个 并 发 HTTP 客户 端 (也 就 是 
TCP/IP 连接 ) 进行 基准 测试 。 令 人 感 兴趣 的 是 每 秒 的 请 求 数量 (吞吐 量 ) ， 以 及 响应 时 间 
的 中 位 数 和 第 99 个 百 分 位 数 。 需 要 提醒 一 下 : 中 位 数 意味 着 50% 的 请 求 响应 速度 满足 给 
定 值 ， 而 第 99 个 百 分 位 数 意味 着 1% 的 请 求 要 比 给 定 的 值 更 慢 。 
基准 环境 
所 有 的 基准 测试 都 运行 在 基于 Linux 3.13.0-62-generic 核心 家 用 笔记 本 电脑 上 ， 
硬件 配置 为 Intel i7 CPU 2.4 GHz，8 GB RAM 和 固态 硬盘 驱动 器 (SSD)。 客 
户 端 机 器 运行 官网 版 本 的 wrk，Gatling 和 JMeter 工具 通过 千 兆 以 太 路 由 器 连接 
至 服务 器 端 机 器 。 客 户 端 和 服务 器 端 机 器 之 间 运 行 ping 的 平均 时 间 为 289 hs 
(偏差 42 hs， 最 低 160 ps)。 
每 项 基准 测试 都 会 至 少 运 行 一 分 钟 ， 包 括 30 秒 对 JDK 1.8.0_66 的 预 热 。 使 
用 的 软件 版 本 为 RxJava 1.0.14、RxNetty 0.5.1 和 Netty 4.0.32.Final。 软 件 负 
载 通 过 htop 进行 测量 。 




































































基准 测试 是 通过 下 面 的 命令 执行 的 (使 用 -c 参数 表示 并 发 客户 端的 数量 )。 
wrk -t6 -c10000 -d60s --timeout 10s --Latency http://server:8080 
1. 返回 200 OK 的 简单 服务 器 
第 一 个 基准 测试 对 比 了 各 种 实现 方式 只 返回 简单 的 200 OK 而 不 执行 任何 后 台 任 务 时 的 性 
能 。 这 个 基准 测试 可 能 不 太 符 合 现实 ,但 是 它 能 够 让 我 们 对 服务 器 和 以 太 网 的 上 限 有 一 个 
































注 1: 不 包括 C 语言 和 其 他 反应 式 平台 ， 如 Node.js。 
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基本 的 了 解 。 在 后 续 的 测试 中 ， 将 会 为 每 个 服务 器 添加 任意 的 休眠 时 间 。 
图 5-1 展现 了 各 个 实现 方式 每 秒 的 请 求 数 (注意 对 数 尺度 )。 
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注意 ， 这 个 基准 测试 仅仅 是 一 个 热身 ， 随 后 服务 器 端 会 运行 一 些 工作 内 容 。 但 是 ， 从 这 

里 ,我们 已 经 能 够 看 出 一 些 有 意思 的 趋势 。 

基于 Netty 和 RxNetty 的 实现 使 用 了 原始 的 TCP/ 耻 ， 吞 叶 量 最 佳 ， 几 乎 达到 了 每 秒 200 000 

个 请 求 。 

不 出 所 料 的 是 ，SingleThread 要 慢 得 多 ， 无 论 并 发 级 别 如 何 ， 它 每 秒 大 约 只 能 处 理 

6000 个 请 求 。 

但 是 ， 在 只 有 一 个 客户 端的 时 候 ，SingteThread 是 最 快 的 实现 方式 。 线 程 池 、 事 件 驱 动 

的 (Rx) Netty 以 及 其 他 实现 方式 的 开销 是 显而易见 的 。 随 着 客户 端 数量 的 增加 ， 这 种 

优势 迅速 消耗 殉 尽 。 此 外 ， 服 务 器 的 吞吐 量 还 高 度 依赖 于 客户 端的 性 能 。 

令 人 稍 感 意外 的 是 ，ThreadPoot 的 运行 效果 非常 好 ， 但 是 在 高 负载 的 情况 下 会 变 得 不 稳 

定 (wrk 报告 了 很 多 错误 )。 遇 到 50 000 个 并 发 连接 时 ,就 会 完全 失败 了 (达到 10 秒 超时 )。 

ThreadPerConnection 开始 运行 得 也 非常 好 ， 但 是 超过 100~200 个 线程 时 ， 服 务 器 的 吞 

量 会 快速 降低 。 同 时 ，50 000 个 线程 会 给 JVM 带 来 很 大 的 压力 ， 尤 其 是 令 人 头疼 的 
额外 千 兆 字 节 的 栈 空间 。 

我 们 不 再 花费 更 多 时 间 来 分 析 这 个 有 点 达 强 的 基准 测试 ， 毕 竞 服 务 器 很 少 直接 返回 一 个 响 

应 。 因 此 ， 我 们 想 要 模拟 一 下 针对 每 个 请 求 都 执行 一 定 的 工作 内 容 的 场景 。 

2. 模拟 服务 器 端的 工作 

为 了 模拟 服务 器 端的 工作 ， 样 例会 在 请 求 和 响应 之 间 注 入 对 sleep() 的 调用 。 这 样 做 也 是 

有 一 定 道理 的 : 服务 器 在 响应 用 户 请 求 的 时 候 ， 通 常 并 不 会 执行 任何 CPU 密集 型 的 任务 。 

传统 的 服务 器 针对 每 个 请 求 会 使 用 一 个 线程 ， 并 在 外 部 资源 上 阻塞 。 而 反应 式 服 务 器 只 需 
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等 待 一 个 外 部 信号 〈 如 包含 响应 的 事件 或 消息 ) ， 同 时 释放 底层 的 资源 。 


鉴于 此 ， 对 于 阻塞 式 的 实现 ， 样 例 只 需要 添加 sleep() 即 可 ， 而 对 于 非 阻塞 的 服务 器 ， 我 
们 会 使 用 0bservable.delay() 或 类 似 的 做 法 ， 以 便 模 拟 调用 非 阻塞 、 慢 响应 的 外 部 服务 ， 
如 下 所 示 。 
public static final Observable<String> RESPONSE = Observable.just( 

"HTTP/1.1 200 OK\r\n" + 

"Content-Length: 2\r\n" + 

"\r\n" + 

"OK") 

.delay(100, MILLISECONDS); 


在 阻塞 式 实现 中 使 用 非 阻 塞 延迟 并 没有 太 大 意义 ， 因 为 即便 底层 实现 是 非 阻 塞 的 ， 服 务 器 
依然 需要 等 待 啊 应 。 也 就 是 说 ， 如 果 为 每 个 请 求 注入 了 100 毫秒 的 延迟 ， 那 么 每 次 与 服务 
器 的 交互 至 少 需要 十 分 之 一 秒 。 现 在 的 基准 测试 更 加 符合 现实 ， 也 更 有 意思 。 每 秒 请 求 数 
与 客户 端 连接 的 关系 如 图 5-2 所 示 。 
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这 个 结果 更 符合 对 真实 负载 的 预期 。 图 的 顶部 是 两 个 基于 Netty 的 实现 (HttpTcpNetty- 
Server 和 HttpTcpRxNettyServer)， 它 们 目前 是 最 快 的 ， 轻 松 实现 每 秒 90 000 个 请 求 
(Request Per Second，RPS)。 实 际 上 ， 在 10 000 个 并 发 客户 端 之 前 ， 服 务 器 是 线性 扩展 
的 。 这 一 点 很 容易 证 明 : 每 个 客户 端 大 约 生成 10 RPS (每 个 请 求 大 约 消 耗 100 毫秒 ， 所 以 
1 秒 内 可 以 发 送 10 个 请 求 ) 。 两 个 客户 端 会 生成 20 RPS，5 个 客户 端 会 生成 50 RPS， 以 此 
类 推 。 在 10 000 个 并 发 连接 的 时 候 ， 预 期 的 结果 是 100 000 RPS， 实 际 上 已 经 接近 理论 极 
限 了 (90 000 RPS)。 


在 底部 ， 我 们 看 到 的 是 singleThread 和 ThreadPool 服务 器 。 它 们 的 性 能 结果 非常 糟糕， 
这 一 点 并 不 令 人 意外 。SingleThread 只 有 一 个 线程 处 理 请 求 ， 而 每 个 请 求 至 少 要 消耗 100 























146 | 第 5 章 


毫秒 ， 那 么 其 处 理 能 力 显然 不 能 超过 10 RPS。ThreadPool 要 好 得 多 ， 它 有 100 个 线程 ， 每 
个 线程 的 处 理 能 力 是 10 RPS， 总 数 能 够 达到 1000 RPS。 与 反应 式 Netty 和 RxJava 实现 相 
比 ， 这 个 数据 差 了 好 几 个 数量 级 。 另 外 ， 在 高 负载 的 情况 下 ，SingteThread 几乎 拒绝 了 所 
有 的 请 求 。 在 大 约 50 000 个 并 发 连接 的 时 候 ， 它 只 能 接收 少量 的 请 求 ， 而 且 几 乎 无 法 满足 
wrk 要 求 的 10 秒 超时 的 限制 。 

你 可 能 会 问 ， 为 什么 要 限制 ThreadPoot 只 有 100 个 线程 呢 ? 因为 这 个 数字 与 流行 的 
HTTP Servlet 容器 的 默认 值 是 比较 接近 的 ， 当 然 样 例 可 以 指定 更 大 的 值 。 连 接 都 是 持久 
的 ， 在 整个 连接 期 间 ， 它 会 一 直 占 用 池 中 的 线程 ， 所 以 可 以 将 ThreadPerConnection 视 
为 没有 任何 线程 数量 限制 的 线程 池 。 令 人 意外 的 是 ， 这 种 实现 方式 运行 得 非常 好 ， 即 便 
是 在 JVM 管理 50 000 个 并 发 线程 (每 个 线程 对 应 一 个 连接 ) 的 时 候 也 是 如 此 。 实 际 上 ， 
ThreadPerConnection 并 没有 比 RxNettyHttpServer 差 太 多 。 事 实证 明 ， 仅 仅 通 过 RPS 来 衡 
量 吞 吐 量 还 是 不 够 的 ， 样 例 还 必须 要 查看 每 个 请 求 的 响应 时 间 。 这 取决 于 需求 ， 但 是 一 般 
情况 下 ， 你 既 需要 高 吞吐 以 便于 充分 利用 服务 器 ， 又 需要 低 延 迟 为 用 户 提供 良好 的 性 能 
体验 。 

平均 响应 时 间 是 一 个 很 好 的 指标 。 一 方面 ， 平 均值 会 隐藏 异常 值 〈 一 些 慢 得 令 人 难以 接受 
的 请 求 ) ， 另 一 方面 ， 典 型 响应 时 间 (大 多 数 客户 端 观察 到 的 值 ) 会 小 于 平均 值 ， 这 同样 
是 那些 异常 值 导致 的 。 事 实证 明 ， 百 分 位 数 会 更 具有 代表 性 ， 它 能 够 有 效 描述 特定 值 的 分 
布 情况 。 图 5-3 展现 了 每 种 服务 器 实现 响应 时 间 的 第 99 个 百 分 位 数 与 并 发 连接 (或 客户 
端 ) 数量 之 间 的 关系 。 了 轴 的 值 代表 99% 的 请 求 都 比 给 定 的 值 更 快 。 显 然 ， 这 些 值 越 小 越 
好 〈 但 是 不 可 能 低 于 模拟 延迟 的 100 毫秒 ) ， 并 且 随 着 负载 的 增加 ， 它 们 增长 得 越 少 越 好 。 
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ThreadPerConnection 实现 方式 非常 突出 。 在 1000 个 并 发 连接 之 前 ， 所 有 实现 方式 的 表现 
不 分 上 下 。 但 是 ， 从 某 个 位 置 开 始 ，ThreadPerConnection 的 响应 就 变 得 非常 慢 了 ， 响 应 时 
间 是 其 他 竞争 对 手 的 几 倍 。 这 种 现象 的 原因 主要 有 两 点 : 首先 ， 上 千 个 线程 会 有 过 量 的 上 
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下 文 切换 ， 其 次 ， 这 种 实现 方式 的 垃圾 收集 频率 会 更 高 。JVM 花费 了 太 多 的 时 间 进 行内 部 
处 理 ， 留 给 实际 工作 的 时 间 非 常 少 。 上 千 个 线程 处 于 空闲 等 待 执行 的 状态 。 


你 可 能 会 惊讶 于 ThreadPool 实现 在 响应 时 间 的 第 99 个 百 分 位 数 上 的 突出 表现 。 它 优 于 
其 他 所 有 的 实现 方式 ， 并 且 在 高 负载 的 情况 下 依然 能 够 保持 稳定 。 让 我 们 简单 看 一 下 
ThreadPoold 实现 方式 大 致 的 样子 ， 如 下 所 示 。 

BlockingQueue<Runnable> workQueue = new ArrayBLockingQueue<>(1000) ; 

executor = new ThreadPoolExecutor(100, 100, OL, MILLISECONDS, workQueue, 


(r, ex) -> { 
((ClientConnection) r).serviceUnavailable(); 


}); 


在 这 里 没有 使 用 Executors 生成 器 (builder)， 而 是 直接 构造 了 ThreadPoolExecutor， 从 而 
完全 控制 workQueue 和 和 RejectedExecutionHandler。 当 workQueue 空间 不 足 时 ， 则 会 运行 
RejectedExecutionHandler。 在 这 里 ， 为 了 防止 服务 器 出 现 过 载 ， 无 法 得 到 快速 处 理 的 请 求 
会 立即 被 拒绝 。 其 他 实现 方式 均 没 有 这 种 安全 特性 ， 它 被 称 为 快速 失败 (fail-fast)。8.2 节 
将 会 简要 介绍 快速 失败 的 功能 。ThreadPoot 方案 的 响应 性 与 其 暴露 的 错误 率 的 关系 ， 如 
5-4 所 示 。 
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除了 SingleThread 和 ThreadPool 实现 ，wrk 负载 测试 工具 对 其 他 实现 均 没 有 报告 错误 。 这 
是 一 种 很 有 意思 的 权衡 :ThreadPool 总 是 能 够 尽快 响应 ， 比 其 他 的 竞争 者 要 快 得 多 ,但 
是 ， 在 它 出 现 超载 的 时 候 ， 也 会 立即 拒绝 请 求 。 当 然 ， 你 也 可 以 基于 Netty/RxJava 的 反应 
式 实现 执行 类 似 的 机 制 。 


总 而 言 之 ， 采 用 线程 池 和 独立 线程 的 方案 无 法 满足 否 吐 量 和 响应 时 间 的 需求 ， 而 这 些 需 求 
可 以 通过 反应 式 实现 来 满足 。 
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5.1.4 反应 式 HTTP 服 务 器 之 旅 


TCP/IP 以 及 基于 它 构建 的 HTTP 本 质 上 都 是 事件 驱动 的 。 尽 管 它 提供 了 输入 和 输出 管道 的 
错觉 ， 但 是 在 底层 可 以 看 到 异步 数据 包 异 步 到 达 。 与 计算 机 科学 领域 的 其 他 抽象 类 似 ， 将 
网 络 栈 视 为 字 贡 组 成 的 阻塞 流 是 有 问题 的 ， 想 要 充分 利用 硬件 时 更 是 如 此 。 


即便 是 在 中 等 负载 的 情况 下 ， 采 用 传统 的 网 络 方式 依然 是 可 行 的 。 但 是 ， 如 果 要 超越 传统 
Java 应 用 程序 的 极限 ， 就 必须 要 采用 反应 式 的 方法 了 。 尽 管 Netty 是 构建 反应 式 、 事 件 驱 
动 的 网 络 应 用 程序 的 优秀 框架 ， 但 是 很 少 直接 使 用 。 相 反 ， 它 会 作为 各 种 库 和 框架 的 一 部 
分 ， 包 括 RxNetty。RxNetty 非常 有 意思 ， 它 将 事件 驱动 网 络 的 优势 与 RxJava 操作 符 的 简 
洁 性 组 合 在 了 一 起 。 我 们 依然 会 将 网 络 通 信 视 为 信息 ( 包 ) 组 成 的 流 ， 不 过 将 其 抽象 成 了 


0ObservabLe<ByteBuf>。 


还 记得 $.1 节 是 如 何 定义 10 000 个 并 发 连接 问题 的 吗 ? 我 们 使 用 各 种 Netty 和 RxNetty 实 
现成 功 解 决 了 这 个 问题 。 实 际 上 ， 成 功 实现 的 服务 器 能 够 经 受 C50k 的 考验 ， 也 就 是 处 理 
50 000 个 并 发 HTTP 持久 化 连接 。 如 果 有 更 多 的 客户 端 硬件 (因为 服务 器 端 运行 得 很 好 ) 
和 更 低 的 请 求 通过 线路 频率 ， 相 同 的 实现 可 以 很 轻松 地 经 受 住 C100k 甚至 更 高 的 并 发 连 
接 ， 而 实现 这 一 点 ， 只 用 了 十 几 行 代码 。 


显然 ， 实 现 HTTP (或 其 他 任何 协议 ， 这 里 以 HTTP 为 例 仅仅 是 因为 它 的 普遍 性 ) 的 服 
务 器 部 分 只 是 整个 过 程 的 一 个 方面 ， 同 样 重要 的 是 服务 器 正在 做 的 事情 。 大 多 数 情况 下 ， 
HTTP 服务 器 会 成 为 其 他 服务 器 的 客户 端 。 到 目前 为 止 ， 本 章 关注 的 是 反应 式 、 非 阻塞 的 
HTTP 服务 器 。 这 样 做 是 合理 的 ， 但 是 阻塞 式 代码 会 在 很 多 出 乎 意料 的 地 方 潜入 。 我 们 过 
度 关注 服务 器 端 ， 而 完全 忽略 了 客户 端 。 但 是 现代 服务 器 也 会 扮演 客户 端的 角色 ， 尤 其 是 
在 分 布 式 系统 中 ， 它 们 会 请 求 数据 并 将 其 推送 至 下 游 服务 。 可 以 大 胆 地 假设 ， 对 流行 搜索 
引擎 的 一 次 请 求 可 能 会 跨越 数 百 甚至 数 千 个 下 游 组 件 ， 从 而 产生 大 量 的 客户 端 请 求 。 显 
然 ， 如 果 这 些 请 求 是 阻塞 式 和 序列 化 的 ， 那 么 搜索 引擎 的 响应 时 间 将 会 非常 长 。 

不 管 服务 器 基础 设施 的 代码 实现 得 多 好 ， 如 果 它 依然 要 处 理 阻塞 式 API， 可 扩展 性 就 会 受 
到 影响 ， 就 像 基准 测试 显示 的 那样 。 特 别 是 在 Java 生态 系统 中 有 一 些 已 知 的 阻塞 源 ， 本 书 
会 进行 简单 地 介绍 。 


5.2 HTTP 客户 端 代码 


向 下 游 服 务 发 送 多 个 请 求 并 将 响应 组 合 在 一 起 的 服务 器 并 不 少见 。 实 际 上 ， 非 常 多 的 初创 
企业 能 够 很 巧妙 地 整合 多 个 可 用 的 数据 源 ， 并 基于 它们 提供 有 价值 的 服务 。 如 今 的 API 大 
多 都 是 RESTful 风格 的 ，SOAP 风格 的 API 在 不 断 减少 ， 但 它们 都 是 基于 HTTP 协议 的 。 
一 个 阻塞 式 请 求 就 可 能 导致 服务 器 停机 ， 严 重 降低 服务 器 的 性 能 。 幸 好 ， 现 在 有 很 多 成 熟 
的 非 阻塞 式 HTTP 客户 端 ， 之 前 见 过 的 Netty 就 是 其 中 一 个 。 非 阻塞 的 HTTP 客户 端 会 试 
图 解决 两 类 问题 ， 如 下 所 示 。 

。 大 量 的 独立 并 发 请 求 ， 每 个 请 求 都 需要 对 第 三 方 API 发 起 多 轮 客户 端 调用 。 这 是 面向 

服务 架构 的 典型 现象 ， 也 就 是 单个 请 求 需要 跨 多 个 服务 。 
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。 服务 器 发 起 大 量 的 HTTP 客户 端 请 求 , 可 能 在 批 处 理 操作 。 考 虑 下 Web 爬虫 或 索引 服务 ， 
它们 会 持续 地 打开 数 千 个 连接 。 

不 管 服务 器 的 特点 是 什么 ， 它 们 的 问题 都 是 相同 的 : 维持 大 量 〈 数 万 甚至 更 多 ) 处 于 打开 
状态 的 HITP 连接 会 带 来 非常 大 的 开销 。 如 果 连 接 的 服务 非常 慢 (此 时 服务 器 是 客户 端的 
身份 )， 问 题 会 更 加 严重 ， 因 此 这 种 情况 下 需要 长 期 持 有 资源 。 

与 之 相反 ，TCP/P 连接 是 非常 轻 量 级 的 。 对 于 每 个 处 于 打开 状态 的 连接 ， 操 作 系统 必须 保 
持 一 个 Socket 描述 符 (大 约 1 KB)， 仅 此 而 已 。 数 据 包 (消息 ) 抵达 时 ， 内 核 会 将 它 分 发 
给 对 应 的 进程 ， 比 如 JVM。 每 个 线程 会 被 阻塞 在 一 个 Socket 中 ， 这 个 线程 栈 会 占用 大 约 
1 MB 的 空间 ， 相 比 之 下 1 KB 就 是 非常 小 的 内 存 占 用 了 。 换 名 话说 ， 在 高 性 能 服务 器 上 ， 
传统 的 每 个 连接 对 应 一 个 线程 的 模型 并 不 能 很 好 地 扩展 ， 需 要 采用 底层 的 网 络 模型 ， 而 不 
是 使 用 阻塞 式 代 码 对 其 进行 抽象 。RxJava + Netty 正好 提供 了 更 好 的 抽象 ， 而 且 相对 接近 
底层 。 


使 用 RxNetty 实 现 非 阻塞 的 HTTP 客 户 端 


RxJava 结合 Netty 提供 了 一 种 抽象 机 制 ， 这 种 抽象 机 制 非常 接近 网 络 的 运行 方式 。 它 没 
有 将 HTTP 请 求 视 为 JVM 中 的 普通 方法 调用 ， 而 是 采用 了 异步 。 另 外 ， 我 们 也 不 能 再 将 
HTTP 视 为 简单 的 请 求 - 响应 协议 。 服 务 器 端 发 送 事 件 (server-sent event， 一 个 请 求 ， 多 
个 响应 )、WebSockets (全 双 工 通信 ) 以 及 最 终 出 现 的 HTTP/2 (在 同一 个 线路 上 进行 多 个 
并 行 的 请 求 和 响应 ， 彼 此 交织 ) 展现 了 HTTP 的 各 种 使 用 场景 。 


在 客户 端 RxNetty 为 简单 的 使 用 场景 提供 了 非常 简洁 的 API。 你 可 以 通过 组 合式 
0bservable 发 起 请 求 并 得 到 响应 ， 如 下 所 示 。 


Observable<ByteBuf> response = HttpClient 
.NewClient("example.com", 80) 
.createGet("/") 
.flatMap(HttpClientResponse: :getContent); 

































































response 
.map(bb -> bb.toString(UTF_8)) 
.Subscribe(System.out::println); 


调用 createGet() 方法 将 会 返回 0bservable<HttpClientResponse> 的 一 个 子 类 。 显 然 ， 客 
户 端 不 会 阻塞 等 待 响应 ， 所 以 0bservable 看 上 去 是 一 个 很 好 的 选择 。 但 这 只 是 开始 。 
HttpClientResponse 有 一 个 getContent() 方法 ， 该 方法 会 返回 0bservabLe<ByteByf>。 回 忆 
一 下 5.1.2 节 ， 里 面 提 到 过 ByteBuf 是 对 线路 接收 数据 块 的 抽象 。 从 客户 端的 角度 来 说 ， 这 
是 响应 的 一 部 分 。 这 没有 什么 问题 ， 但 是 RxNetty 比 其 他 非 阻塞 HTTP 客户 端 更 进一步 。 
在 整个 响应 到 达 的 时 候 ， 它 不 会 简单 地 发 出 通知 ， 相 反 ， 我 们 会 得 到 一 个 ByteBuf 消息 的 
流 ， 随 后 是 一 个 可 选 的 bbservablte 完成 通知 。 服 务 器 端 决 定 放弃 连接 的 时 候 ， 我 们 就 会 得 
到 Observable 完成 通知 。 

这 样 的 模型 非常 接近 TCP/IP 栈 的 运行 方式 ， 并 且 在 用 例 中 能 够 更 好 地 扩展 。 它 能 够 与 简 
单 的 请 求 /响应 流 协作 ， 也 能 够 用 于 复杂 的 流 场景 。 但 是 ， 需 要 注意 ， 即 便 是 在 单个 响应 
的 情况 下 ， 比 如 包含 HTML 的 请 求 ， 它 也 很 可 能 以 多 个 数据 块 的 方式 抵达 。 当 然 ，RxJava 
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有 多 种 方式 将 它们 组 装 回来 ， 比 如 0bservable.toList() 或 Observable.reduce()。 这 取决 
于 你 : 如 果 你 想 要 在 数据 抵达 的 时 候 ， 以 小 数据 段 的 方式 进行 消费 ， 这 完全 没有 问题 。 在 
这 种 情况 下 ，RxNetty 的 抽象 级 别 是 比较 低 的 ， 但 是 这 种 抽象 没有 引入 大 的 性 能 瓶 开 ， 比 
如 过 多 的 缓冲 或 阻塞 ， 所 以 扩展 性 会 非常 好 。 如 果 你 想 要 使 用 健壮 而 且 更 高 级 的 反应 式 
HTTP 客户 端 ， 可 以 参考 8.1.2 节 。 


与 基于 回调 的 反应 式 API 不 同 ，RxNetty 能 够 很 好 地 与 其 他 0bservable 协作 ， 你 可 以 很 方 
便 地 对 工作 进行 并 行 处 理 、 组 合 和 切 分 。 例 如 ， 假 设 现在 有 一 个 URL 的 流 ， 必 须 实时 连接 
并 消费 数据 。 这 个 流 可 能 是 固定 的 (从 简单 的 List<URL> 构建 而 来 ) ， 也 可 能 是 动态 的 ， 也 
就 是 新 的 URL 会 随时 出 现 。 如 果 你 想 要 一 个 稳定 的 由 数据 包 组 成 的 流 ， 并 且 要 访问 所 有 的 
资源 ， 那 么 可 以 对 它们 进行 fLatMap() 操作 。 


Observable<URL> sources = //... 















































Observable<ByteBuf> packets = 
sources 
.flatMap(url -> HttpClient 
.NewClient(url.getHost(), url.getPort()) 
.CreateGet(url.getPpath())) 
.flatMap(HttpClientResponse: :getContent); 


这 个 例子 稍微 有 些 牵 强 ， 它 将 来 自 不 同 源 的 ByteBuf 消息 混合 在 了 一 起 ， 但 是 你 要 掌握 其 
中 的 思想 。 对 于 上 游 0bservable 中 的 每 个 URL， 都 会 根据 该 URL 生成 一 个 由 ByteByf 实例 
组 成 的 异步 流 。 如 果 你 想 要 先 转换 传人 的 数据 ， 可 能 需要 将 数据 块 组 合成 一 个 事件 ， 这 很 
容易 实现 ， 比 如 通过 reduce()。 最 终 的 结果 就 是 这 样 : 你 可 以 轻松 拥有 数 万 个 处 于 打开 
状态 的 HITP 连接 ， 它 们 要 么 处 于 空闲 状态 ， 要 么 在 接收 数据 。 这 里 的 限制 因素 并 不 是 内 
存 ， 而 是 CPU 的 处 理 能 力 以 及 网 络 带宽 。 如 果 要 处 理 合 理 数 量 范围 内 的 事务 ，JVM 并 不 
需要 GB 级 别 的 内 存 消耗 。 


在 现代 应 用 程序 中 ，HTTP 的 API 是 一 个 重要 的 瓶颈 。 在 CPU 方面 ， 它 们 并 不 昂贵 ， 但 是 
阻塞 式 的 HTTP 就 像 普通 的 方法 调用 一 样 ， 大 大 限制 了 扩展 性 。 即 便 你 小 心 村 村 地 移 除 了 
阻塞 式 的 HTTP 通信 ， 同 步 代 码 还 是 会 在 意 想 不 到 的 地 方 出 现 。java.net.URL 的 equals() 
方法 有 一 个 缺陷 ， 就 是 它 会 发 起 网 络 调用 。 当 你 对 比 URL 类 的 两 个 实例 时 ， 这 个 看 似 很 快 
的 方法 其 实 会 发 起 一 轮 网 络 的 往返 (调用 序列 ， 自 上 而 下 读 取 )。 


java.net.URL.equals(URL.java) 

java.net.URLStreamHandler .equals(URLStreamHandler .java) 
java.net.URLStreamHandler .sameFile(URLStreamHandler .java) 
java.net.URLStreamHandler .hostsEqual(URLStreamHandler .java) 
java.net.URLStreamHandler .getHostAddress(URLStreamHandler .java) 
java.net. InetAddress.getByName(InetAddress .java) 
java.net.InetAddress.getAllByName(InetAddress .java) 
java.net.InetAddress.getALLByName0(InetAddress.java) 
java.net.InetAddress.getAddressesFromNameService(InetAddress.java) 
java.net.InetAddress$2.LookupALLHostAddr(InetAddress.java) 
[native code] 


为 了 判断 两 个 URL 是 否 相 等 ，JVM 会 调用 lookupAtlHostAddr()， 它 (在 native 代码 中 ) 
会 调用 gethostbyname (或 类 似 的 方法 )， 向 DNS 服务 器 发 起 一 次 同步 请 求 。 如 果 你 的 线 
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程 数 量 有 限 ， 并 且 其 中 有 一 部 分 意外 阻塞 时 ， 这 可 能 会 造成 灾难 性 的 影响 。 还 记得 基于 
RxNetty 的 服务 器 吗 ? 它们 最 多 只 会 使 用 几 十 个 线程 。 另 外 一 种 灾难 性 的 场景 就 是 频繁 调 
用 URL.equals() 的 时 候 ， 比 如 在 Set<URL> 中 。URL 这 种 意料 之 外 的 行为 是 众所周知 的 ， 这 
就 好 比 一 个 事实 : 它 的 equals() 实际 会 生成 的 结果 取决 于 Internet 的 连接 状况 。 


指出 这 一 点 只 是 为 了 说 明 编写 反应 式 应 用 程序 非常 困难 ， 而 且 陷 阱 重重 。 下 一 市 将 会 介绍 
另外 一 个 更 明显 的 阻塞 源 : 数据 库 访 问 代码 。 


5.3 关系 数据 库 访 问 


在 前 面 的 部 分 ， 我 们 已 经 得 出 结论 : 每 个 服务 器 最 终 都 会 成 为 不 同 服务 的 客户 端 。 还 有 一 
个 非常 有 意思 的 现象 ， 目 前 使 用 的 计算 机 系统 几乎 全 都 是 分 布 式 的 。 由 网 线 连接 的 两 台 计 
算 机 需要 进行 通信 时 ， 在 空间 上 实际 已 经 是 分 布 式 的 了 。 更 极端 一 点 ， 你 可 以 将 每 台 计算 
机 都 想象 成 一 个 分 布 式 系统 ， 各 个 独立 的 CPU 核心 缓存 并 不 总 是 一 致 的 ， 它 们 必须 通过 
消息 传递 协议 来 实现 同步 。 现 在 ， 让 我 们 对 比 一 下 应 用 程序 服务 器 和 数据 库 服务 器 架构 。 

在 Java 领域 ， 关 系数 据 库 访 问 长 期 存在 的 标准 是 Java 数据 库 连 接 (Java Database 
Connectivity，JDBC)。 从 消费 者 的 角度 来 说 ，JDBC 提供 了 一 组 API 与 关系 数据 库 进行 通 
信 ， 这 些 数 据 库 包括 PostgreSQL、Oracle Database 等 。 核 心 的 抽象 是 Connection (TCP/ 
IP， 线 路 连接 )、Statement (数据 库 查 询 ) 和 Resultset (查看 数据 库 结果 )。 如 今 ， 开 发 
人 员 很 少 会 直接 使 用 这 个 API， 因 为 已 经 有 了 更 易于 使 用 的 抽象 ， 从 Spring 框架 中 轻 量 级 
的 JdbcTempLate， 到 像 jOOQ 这 样 的 代码 生成 库 ， 再 到 像 JPA 这 样 的 对 象 - 关系 映射 解决 
方案 。JDBC 在 错误 处 理 与 检查 型 异常 (自从 Java 7 提供 了 try-with-resources 后 已 经 简单 
了 很 多 ) 方面 饱 受 争议 。 


import java.sql.*; 

































































































































































try ( 
Connection conn = DriverManager .getConnection("jdbc:h2:mem:"); 
Statement stat = conn.createStatement(); 
ResultSet rs = stat.executeQuery("SELECT 2 + 2 AS total") 

) { 


if (rs.next()) { 
System.out.println(rs.getInt("total")); 
assert rs.getInt("total") == 4; 
} 
} 


上 述 的 样 例 使 用 了 欣 入 式 的 H2 数据 库 ， 这 个 数据 库 通 常用 来 进行 集成 测试 。 但 是 在 生产 
环境 中 ， 数 据 库 实 例 和 应 用 程序 很 少 运行 在 同一 台 机 器 上 。 每 次 与 数据 库 的 交互 都 需要 一 
次 网 络 往返 。JDBC 的 核心 是 它 的 API， 每 个 数据 库 厂 商都 要 实现 该 API。 


请 求 JDBC 的 API 获取 新 的 Connection 时 ，API 的 实现 必须 要 发 起 一 个 到 数据 库 的 物理 连 
接 ， 这 涉及 打开 客户 端 Socket、 授 权 等 操作 。 数 据 库 有 不 同 的 线路 协议 (几乎 都 是 二 进 制 
的 )，JDBC 实现 (也 被 称 为 briver) 的 责任 就 是 将 底层 的 网 络 协议 转换 为 一 致 的 API。 这 
种 方式 运行 得 非常 好 〈 抛 开 不 同 的 SQL 方言 不 谈 ) ， 但 是 在 1997 年 发 布 JDBC 标准 和 JDK 
1.1 的 时 候 ， 没 有 人 预料 到 20 年 后 反应 式 和 异步 编程 会 变 得 如 此 重要 。 当 然 ，API 经 历 了 
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很 多 的 版 本 ， 但 是 都 是 固有 阻塞 的 ， 等 待 每 个 数据 库 操作 完成 。 


这 其 实 和 之 前 讨论 的 HITP 问题 相同 。 应 用 程序 中 必须 包含 与 活跃 数据 库 操 作 (查询 ) 数 
量 相同 的 线程 。JDBC 是 以 可 移植 的 方式 访问 各 种 关系 数据 库 的 唯一 成 熟 标准 (再 次 强调 ， 
暂时 不 考虑 不 同 SQL 方言 的 差异 ) 。 几 年 前 ，Servlet 规范 在 3.0 版 本 有 了 显著 的 改进 ， 引 
入 了 HttpServletRequest.startAsync() 方 法。 但 非常 糟糕 的 是 ，JDBC 标准 依然 固守 着 经 
典 的 模型 。 


JDBC 保持 阻塞 有 多 重 原因 。Web 服务 器 可 以 很 轻松 地 处 理 数 十 万 个 处 于 打开 状态 的 连接 。 
例如 ， 如 果 HTTP 连接 上 只 是 偶尔 流动 一 小 段 数 据 。 另 一 方面 ， 数 据 库 系 统 会 对 每 个 客户 
端 查询 执行 几 个 类 似 的 步骤 ， 如 下 所 示 。 


(1) 查询 解析 (CPU 密集 ) : 将 一 个 包含 查询 的 String 转换 为 一 个 解析 树 。 

(2) 查询 优化 器 (CPU 密集 ) : 基于 各 种 规则 和 统计 数据 对 查询 进行 评估 ， 举 试 构建 执行 计划 。 
(3) 查询 执行 器 (1/O 密集 ) : 遍历 数据 库存 储 并 找到 要 返回 的 元 组 。 

(4) 结果 集 (网 络 密集 ) : 被 序列 化 并 被 推送 至 客户 端 。 


显然 ， 所 有 数据 库 都 需要 大 量 的 资源 去 执行 查询 。 通 常 ， 大 多 数 时 间 实 际 都 花费 在 查询 执 
行 上 。 而 且 根据 设计 ， 磁 盘 (不 管 是 旋转 磁盘 还 是 SSD 磁盘 ) 并 不 能 很 好 地 支持 并 行 执 
行 。 因 此 ， 数 据 库 系 统 在 达到 饱和 之 前 ， 能 执行 的 并 发 查询 的 数量 是 有 限制 的 。 这 个 限制 
在 很 大 程度 上 取决 于 实际 使 用 的 数据 库 引 擎 以 及 运行 的 硬件 ， 还 有 其 他 一 些 不 太 明 显 的 
方面 ， 比 如 锁 、 上 下 文 切 换 以 及 CPU 缓存 耗 尽 。 我 们 预期 的 结果 应 该 是 每 秒 数 百 个 查询 ， 
非 阻塞 API 能 够 轻松 维持 数 十 万 个 处 于 打开 状态 的 HTTP 连接 ， 相 比 之 下 ， 数 据 库 的 处 理 
能 力 就 显得 太 低 了 。 


我 们 已 经 知道 数据 库 的 吞吐 量 严重 受 限 于 硬件 ， 采 用 完全 的 反应 式 驱动 也 没有 太 大 的 意 
义 。 从 技术 上 讲 ， 你 可 以 基于 Netty 或 RxNetty 实现 一 个 线路 协议 ， 避 免 阻 塞 客户 端 线程 。 
实际 上 ， 许 多 非 标准 的 、 独 立 开发 的 方式 (参见 postgresql-async、postgres-async-driver、 
adbcj 和 finagle-mysql) 都 尝试 用 非 阻 塞 网 络 栈 实现 特定 数据 库 的 线路 协议 。 但 是 ，JVM 
只 能 轻松 地 处 理 几 百 到 几 千 个 线程 (参见 A.2 节 )， 从 头 重 写 已 经 很 完善 的 JDBC API 并 不 
会 带 来 太 大 的 益处 。Lightbend 常用 的 反应 式 技术 栈 由 Akka 工具 包 支 持 ， 但 是 它 的 Slick 
在 底层 使 用 的 也 是 JDBC。 另 外 ， 还 有 社区 主导 的 项 目 致 力 于 弥合 RxJava 和 JDBC 之 间 的 
鸿沟 ， 比 如 rxjava-jdbc。 


关于 如 何 与 关系 数据 库 进行 交互 ， 我 们 建议 使 用 一 个 专用 的 、 经 过 仔细 调 优 的 线程 池 ， 将 
阻塞 式 代 码 隔 离 在 这 里 。 这 样 应 用 程序 的 其 他 部 分 就 能 实现 高 度 的 反应 性 ， 并 且 只 需 对 
少量 的 线程 进行 操作 。 但 是 从 实用 的 角度 来 看 ， 还 是 应 当 继续 使 用 JDBC， 将 其 替换 为 
更 加 反应 式 的 方式 会 带 来 很 多 麻烦 ， 并 且 没 有 明显 的 收益 。4.1 节 已 经 给 出 了 在 经 典 软件 
栈 中 如 何 与 JDBC 进行 交互 的 一 些 提 示 。 即 便 是 基于 阻塞 式 的 JDBC， 我 们 依然 可 以 使 用 
RxJava 进行 一 些 实验 。 
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在 PostgreSQL 中 使 用 NOTIFY 和 LISTEN 的 案例 


PostgreSQL 内 置 了 一 个 特殊 的 消息 机 制 |， 它 是 通过 扩 展 的 SQL 语句 LISTEN 和 NOTIFY 实现 
的 。 每 个 PostgreSQL 客户 端 都 可 以 通过 SQL 语句 向 虚拟 通道 (channel) 发 送 通知 ， 如 下 
所 示 。 


NOTIFY my_channel; 
NOTIFY my_channel, '{"answer": 42}'; 


本 例 首 先 发 送 了 一 条 空 的 通知 ， 随 后 发 送 了 一 个 任意 的 字符 串 〈 它 可 以 是 JSON、XML 或 
者 是 其 他 编码 格式 的 数据 ) 到 my_channel 通道 。 换 言 之 ， 通 道 就 是 一 个 由 PostgreSQL 数 
据 库 引 获 管 理 的 队列 。 比 较 有 意思 的 是 ， 发 送 通知 是 事务 的 一 部 分 ， 所 以 消息 的 投递 会 在 
提交 之 后 进行 ， 如 果 出 现 回 滚 ， 消 息 将 会 被 丢弃 。 


为 了 消费 特定 通道 的 通知 ， 首 先 要 通过 LISTEN 监听 该 通道 。 监 听 指 定 的 连接 时 ， 获 取 通 知 
的 唯一 办 法 就 是 使 用 getNotifications() 方法 进行 定期 轮 询 。 这 会 导致 随机 的 延迟 、 不 必 
要 的 CPU 负载 和 上 下 文 切 换 。 但 令 人 遗憾 的 是 ， 它 的 API 就 是 这 样 设计 的 。 完 整 的 阻塞 
式 代码 样 例如 下 所 示 。 
try (Connection Connection = 
DriverManager .getConnection("jdbc:postgresql:db")) { 


try (Statement statement = connection.createStatement()) { 
statement.execute( "LISTEN my_channel"); 

















} 


Jdbc4Connection pgConn = (Jdbc4Connection) connection; 
pollForNotifications(pgConn); 


} 
/1... 


void pollForNotifications(Jdbc4Connection pgConn) throws Exception { 
while (!Thread.currentThread().isInterrupted()) { 
final PGNotification[] notifications = pgConn.getNotifications(); 
if (notifications != null) { 
for (final PGNotification notification : notifications) { 
System.out.printLn( 
notification.getName() + ": "+ 
notification.getParameter()); 
} 


} 
TimeUnit.MILLISECONDS. sleep(100); 


} 


样 例 不 仅 会 阻塞 客户 端 线程 ， 还 必须 保持 一 个 JDBC 连接 处 于 打开 状态 ， 因 为 监听 是 关联 
到 特定 连接 的 。 不 过 ， 0 以 同时 监听 多 个 通道 了 。 上 述 代码 很 烦 瑞 ， 但 是 很 简单 
直接 。 在 调用 LISTEN 之 后 ， 样 例会 进入 一 个 不 会 退出 的 循环 ， 以 便于 获取 新 的 通知 。 调 用 
getNotifications() 是 有 破坏 性 的 ， 这 意味 着 它 会 丢弃 返回 的 通知 ， 所 以 调用 它 两 次 不 会 
返回 相同 的 事件 。getName() 能 够 得 到 通道 的 名 称 (例如 my_channel)，getParameter() 则 
会 返回 可 选 的 事件 内 容 ， 比 如 JSON 载荷 。 









































这 个 API 已 经 过 时 了 ， 比 如 它 使 用 null 表示 没有 待 处 理 的 通知 ， 使 用 数组 而 不 是 集合 。 
接 下 来 ,让 它 变 得 对 Rx 更 加 友好 一 些 。 由 于 缺少 推送 通知 的 机 制 ， 必 须 使 用 非 阻塞 的 
interval() 操作 符 重 新 实现 轮 询 。 有 很 多 小 细 市 能 够 让 自 定义 的 Observable 行为 更 加 合 
理 ， 在 以 下 样 例 〈 尚 未 完成 ) 之 后 ， 我 们 会 进一步 讨论 。 


Observable<PGNotification> observe(String channel, long poLLingPeriod) { 
return Observable.<PGNotification>create(subscriber -> { 
try { 
Connection connection = DriverManager 
.getConnection("jdbc:postgresql:db"); 
subscriber.add(Subscriptions.create(() -> 
closeQuietly(connection))); 
listenOn(connection, channel); 
Jdbc4Connection pgConn = (Jdbc4Connection) connection; 
pollForNotifications(pollingPeriod, pgConn) 
.Subscribe(Subscribers.wrap(subscriber); 
} catch (Exception e) { 
subscriber .onError(e); 

















} 
}) .share(); 


void Listen0n(Connection connection, String channeL) throws SQLException { 
try (Statement statement = connection.createStatement()) { 
statement.execute("LISTEN " + channel); 


} 
} 


void closeQuietly(Connection connection) { 
try { 
connection.close(); 
} catch (SQLException e) { 
e.printStackTrace(); 
} 
} 


如 果 没 有 SQLException， 代 码 将 会 惊人 的 短 。 但 是 ， 不 要 介意 ， 我 们 的 目标 是 生成 健壮 的 
0bservabLe<PGNotification>。 首 先 ， 样 例 推 迟 了 打开 数据 库 连 接 的 行为 ， 真 正 有 人 订阅 
的 时 候 才 会 执行 。 同 时 ， 为 了 避免 连接 泄漏 (对 于 直接 处 理 JDBC 的 应 用 程序 来 说 ， 这 是 
非常 严重 的 问题 ) ，Subscriber 取消 订阅 的 时 候 ， 样 例 应 该 确保 连接 能 够 正常 关闭 。 另 外 ， 
流出 现 错误 的 时 候 会 取消 订阅 ， 从 而 也 能 实现 连接 的 关闭 。 

现在 ， 样 例 做 好 了 调用 tlistenon() 的 准备 ， 开 始 通过 打开 的 连接 接收 通知 。 如 果 在 执行 这 
个 语句 的 时 候 抛 出 异常 ， 将 通过 调用 subscriber.onError(e) 捕获 和 处 理 异 常 。 它 不 仅 会 
将 错误 无 颖 地 传递 给 订阅 者 ， 还 会 强制 关闭 连接 。 但 是 ， 如 果 LISTEN 请 求 成 功 ， 下 一 次 调 
用 getNotifications() 将 会 返回 此 后 发 送 的 所 有 事件 。 

我 们 不 想 阻塞 任何 的 线程 ， 所 以 在 pollForNotifications() 中 ， 使 用 interval() 创建 


了 一 个 内 部 的 0bservable。 样 例 使 用 相同 的 Subscriber 订阅 该 0bservable， 但 是 使 用 
Subscribers.wrap() 进行 了 包装 ， 这 样 onStart() 就 不 会 在 这 个 Subscriber 上 执行 两 次 。 
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Observable<PGNotification> pollForNotifications( 
Long pollingPeriod, 
AbstractJdbc2Connection pgConn) { 

return Observable 

.interval(0, pollingPeriod, TimeUnit.MILLISECONDS) 
.flatMap(x -> tryGetNotification(pgConn)) 
.filter(arr -> arr != null) 
.flatMapIterable(Arrays::asList); 

} 


Observable<PGNotification[]> tryGetNotification( 
AbstractJdbc2Connection pgConn) { 
try { 
return Observable.just(pgConn.getNotifications()); 
} catch (SQLException e) { 
return Observable.error(e); 
} 
} 


我 们 会 定期 检查 getNotifications() 的 内 容 。 首 先 把 它们 包装 在 一 个 看 上 去 有 些 笨重 的 
0bservabLe<PGNotification[]> 中 。 返 回 的 数组 PGNotification[] 可 能 会 是 nuLL， 所 以 用 
filter() 过 滤 掉 null 值 ， 然 后 通过 flatMapIterable() 打开 数组 ， 先 是 使 用 Arrays: :asList 
将 其 转换 为 List<PGNotificatiton>。 建 议 你 仔细 看 一 下 这 些 步 又 ， 跟 踪 中 间 0bservable 的 
类 型 。 这 里 之 所 以 会 包含 closeQuietly() 和 tryGetNotification()， 是 为 了 处 理 检查 型 异常 
(SQLException)。 注 意 ， 这 个 异常 在 closeQuietly() 中 以 静默 的 方式 处 理 ， 因 为 在 该 调用 的 
上 下 文中 无 法 采取 其 他 的 措施 。 例 如 ， 如 果 有 人 恰好 在 这 时 取消 订阅 ， 就 不 能 转发 该 异常 。 
实现 的 最 后 一 个 细节 是 publish() 和 refCount()， 接 近 第 一 个 方法 的 结尾 。 这 两 个 方法 
能 够 在 多 个 订阅 者 之 间 共 享 一 个 JDBC 连接 。 如 果 没 有 它们 ， 每 个 新 的 订阅 者 都 会 创建 
一 个 新 连接 并 进行 监听 ， 这 是 非常 浪费 的 。 另 外 ，refCount() 会 跟踪 订阅 者 的 数量 ， 最 
后 一 个 订阅 者 取消 订阅 的 时 候 ， 它 会 关闭 数据 库 连接 。 参 见 2.7.1 节 ， 了 解 publish() 和 
refCount() 的 更 多 细节 ， 尤 其 要 关注 它 如 何 改变 了 0bservable.create() 中 lambda 表达 式 
的 行为 。 
需要 注意 ， 一 个 连接 可 以 监听 多 个 通道 。 作 为 练习 ， 你 可 以 尝试 实现 observe()， 以 便 在 
所 有 订阅 者 和 他 们 感 兴趣 的 所 有 通道 之 间 重 用 相同 的 连接 。 如 果 执 行 一 次 observe() 并 多 
次 进行 订阅 ， 当 前 的 实现 家 ee kt 享 同一 个 连接 。 其 实 它 可 以 一 直 重 用 同一 个 连接 ， 即 便 订 
阅 者 感 兴趣 的 是 不 同 的 通 


ee 攻 丽人 
可 靠 的 消息 队列 。 但 是 这 个 案例 展现 了 如 何在 更 加 反应 式 的 场景 中 发 挥 JDBC， 即 便 还 需 
要 一 些 阻塞 和 轮 询 的 机 制 。 
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5.4 CompletableFuture 与 Stream 


除了 1lambda 表达 式 、 新 的 java.time API 以 及 几 个 小 的 功能 增强 ，Java8 还 提供 了 
CompletableFuture 类 。 这 个 类 显著 增强 了 自 Java 5 以 来 的 Future。 单 纯 的 Future 代表 一 
个 在 后 台 执 行 的 异步 操作 ， 通 常会 由 ExecutorService 生成 。 但 是 ，Future 的 API 过 于 简 











单 ， 迫 使 开发 人 员 一 直 阻 塞 对 Future.get() 的 调用 。 我 们 必须 采用 一 直 繁 忙 等 待 的 方式 ， 
才能 得 到 第 一 个 完成 的 Future。 在 这 方面 ， 根 本 没有 其 他 的 组 合 方案 。5.4.1 节 会 简要 介绍 
一 下 CompletableFuture 是 如 何 运 行 的 。 随 后 ， 我 们 会 在 CompletableFuture 和 0bservable 
之 间 实 现 一 个 很 薄 的 中 间 层 。 








5.4.1 CompletableFuture 概 述 


Observable 提供 了 儿 十 种 有 用 的 方法 ， 成 功 弥 合 了 这 一 鸿沟 ， 这 些 方 法 大 多 数 都 是 非 阻 
塞 和 可 组 合 的 。 我 们 已 经 习惯 于 使 用 map() 在 运行 时 异步 转换 传 入 的 事件 。 除 此 之 外 ， 
Observable.flatMap() 能 够 将 单个 事件 替换 成 Observable， 从 而 将 异步 任务 链接 起 来 。 类 
似 的 操作 可 以 通过 CompletableFutures 实现 。 假 设 有 个 服务 需要 两 条 不 相关 的 信息 : User 
和 GeoLocation。 在 获取 到 它们 之 后 ， 样 例会 请 求 几 家 独立 的 旅行 社 查 询 航 班 信息 (实体 
为 Flight)， 并 在 返回 最 快 的 供应 商 那 里 订 票 (实体 为 Ticket)。 最 后 这 个 需求 其 实 最 难 实 
现 ， 在 Java 8 之前， 使 用 ExecutorCompletionService 才能 找到 响应 最 快 的 任务 。 


User findById(long id) { 
Ls 















































} 


GeoLocation locate() { 
//... 
} 


Ticket book(Flight flight) { 
//... 


interface TravelAgency { 
Flight search(User user, GeoLocation location); 


} 
使 用 方式 如 下 。 


ExecutorService pool = Executors.newFixedThreadPool(10); 
List<TravelAgency> agencies = //... 


User user = findById(id); 
GeoLocation location = locate(); 
ExecutorCompletionService<Flight> ecs = 

new ExecutorCompletionService<>(pool); 
agencies.forEach(agency -> 

ecs.submit(() -> 

agency.search(user, location))); 

Future<Flight> firstFlight = ecs.poll(5, SECONDS); 
Flight flight = firstFlight.get(); 
book(flight); 


在 Java 开发 人 员 中 ，ExecutorCompletionService 并 不 流行 ， 而且 有 了 CompletableFuture 
之 后 ， 根 本 就 不 再 需要 它 了 。 但 是 ， 在 这 里 首先 会 看 到 ExecutorCompletionService 怎样 包 
装 了 ExecutorService。 包 装 完成 之 后 ， 就 可 以 通过 poll 方法 在 完成 的 任务 到 达 时 获取 结 
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果 。 如 果 单 纯 地 使 用 ExecutorService， 会 得 到 一 堆 Future 对 象 ， 完 全 不 知道 哪 一 个 会 率 
先 完 成 ， 所 以 ExecutorCompletionService 的 作用 就 发 挥 了 出 来 。 但 是 ， 这 里 依然 需要 一 个 
额外 的 线程 来 阻塞 等 待 TravelAgency 的 响应 。 另 外 ， 我 们 并 没有 充分 发 挥 并 发 的 优势 〈 同 
时 加 载 User 和 GeoLocation ) 。 

重 构 会 首先 将 所 有 的 方法 转换 成 异步 方法 ， 然 后 对 CompletableFuture 进行 相应 的 组 合 。 
通过 这 种 方式 ， 代 码 将 会 变 成 完全 非 阻 塞 的 (主线 程 几乎 可 以 立即 完成 )， 可 以 尽 可 能 地 
实现 并 行 化 。 

CompletableFuture<User> findByIdAsync(long id) { 
return CompletableFuture.supplyAsync(() -> findById(id)); 
































} 


CompletableFuture<GeoLocation> locateAsync() { 
return CompletableFuture.supplyAsync(this::locate); 


} 


CompletableFuture<Ticket> bookAsync(Flight flight) { 
return CompletableFuture.supplyAsync(() -> book(flight)); 


} 


@Override 
public CompletableFuture<Flight> searchAsync(User user, GeoLocation location) { 
return CompLetabLeFuture.suppLyAsync(() -> search(user, location)); 


} 


以 上 只 是 使 用 异步 CompletableFuture 将 阻塞 式 代码 包装 了 起 来 。supplyAsync() 方法 会 接收 
一 个 可 选 的 Executor 作为 参数 。 如 果 没 有 指定 ， 那 么 将 会 使 用 ForkJotnPooL.commonPootL() 
中 定义 的 全 局 Executor。 建 议 始 终 使 用 自 定义 的 Executor， 但 样 例 这 里 就 使 用 默认 的 
Executor 了 。 需 要 注意 ， 这 个 默认 的 Executor 会 在 所 有 的 CompletableFuture、 并 行 流 ( 参 
见 8.5 节 ) 和 其 他 几 个 不 太 明 显 的 位 置 共享 。 


import static java.util.function.Function.identity; 




















List<TravelAgency> agencies = //... 
CompletableFuture<User> user = findByIdAsync(id); 
CompletableFuture<GeoLocation> location = locateAsync(); 


CompletableFuture<Ticket> ticketFuture = user 
.thenCombine(location, (User us, GeoLocation Loc) -> agencies 
.Stream() 
.map(agency -> agency.searchAsync(us, loc)) 
.reduce((f1，f2) -> 
f1i.applyToEither(f2, identity()) 
) 
.get() 
) 
.thenCompose(identity()) 
.thenCompose(this: :bookAsync); 


看 的 代码 片段 中 发 生 了 很 多 的 事情 。 完 整地 阐述 CompletableFuture 已 经 超出 了 本 





在 上 
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三 


书 的 范围 ， 但 是 有 些 API 在 RxJava 环境 中 是 非常 有 用 的 。 首 先 ， 样 例 异 步 地 获取 User 
和 GeoLocation 信息 。 这 两 个 操作 是 独立 的 ， 可 以 并 发 运行 。 但 是 想 要 获取 它们 的 结 
果 ， 显 然 不 能 阻塞 和 浪费 客户 端 线程 。 这 就 是 thenCombine() 做 的 事情 。 它 接收 两 个 
CompletableFuture (user 和 Location) ， 并 在 两 者 都 完成 的 时 候 ， 异 步 执行 一 个 回调 。 有 
意思 的 是 ， 这 个 回调 可 以 返回 一 个 值 ， 这 个 值 将 会 成 为 最 终 形 成 的 CompletableFuture 的 
新 内 容 ， 如 下 所 示 。 


CompletableFuture<Long> timeFuture = //... 
CompLetabLeFuture<ZoneId> zoneFuture = //... 


























CompLetabLeFuture<Instant> instantFuture = timeFuture 
.thenApply(time -> Instant.ofEpochMilli(time)); 


CompletableFuture<ZonedDateTime> zdtFuture = instantFuture 
.thenCombine(zoneFuture, (instant, zoneId) -> 
ZonedDateTime.ofInstant(instant, zoneld)); 


CompletableFuture 与 Observable 有 很 多 相似 之 处 。thenApply() 会 对 Future 返回 的 值 执 行动 态 
转换 ， 这 类 似 于 0bservable.map()。 样 例 提供 了 一 个 从 Long 到 Instant (Instant: :ofEpochMiLLLL ) 
的 函数 ， 从 而 将 CompLetabLeFuture<Long> 转换 为 CompLetabLeFuture<Instant>。 随 后 ， 接 收 两 个 
Future (instantFuture 和 zoneFuture)， 使 用 thenCombine() 对 它们 的 值 (Instant 和 zoneId) 
进行 转换 。 这 次 转换 会 返回 ZoneDateTime， 但 是 因为 大 多 数 的 CompletableFuture 操作 
符 都 是 非 阻 塞 的 ， 在 返回 值 中 得 到 的 是 CompLetabLeFuture<ZonedDateTime>， 这 个 过 程 与 
Observable 中 的 zip() 非常 类 似 。 我 们 回 到 之 前 订 票 的 样 例 ， 下 面 的 代码 片段 可 能 会 有 些 
星 涩 难 懂 。 


List<TravelAgency> agencies = //... 




































































agencies 
.Stream() 
.map(agency -> agency.searchAsync(uyus, loc)) 
.reduce((f1, f2) -> 
f1.applyToEither(f2, identity()) 
) 
.get() 
样 例 需 要 在 每 个 TravelAgency 上 通过 调用 searchAsync() 来 启动 异步 操作 。 调 用 之 
后 ， 马 上 就 会 得 到 一 个 List<CompletableFuture<Flight>>。 如 果 只 想 要 第 一 个 完成 的 
Future， 这 个 数据 结构 操作 起 来 就 非常 不 便利 了 。 为 了 解决 这 个 问题 ， 样 例 可 以 使 用 
CompletableFuture.all0f() 和 CompletableFuture.any0f() 这 样 的 方法 。 在 语义 上 ， 后 者 
恰好 是 需要 的 。 它 会 接收 一 组 CompletableFuture， 并 在 第 一 个 底层 的 CompletableFuture 
完成 之 后 ， 返 回 一 个 CompLetabLeFuture， 然 后 丢弃 所 有 其 他 的 CompletableFuture。 这 类 似 
于 Observable.amb() (参见 3.2.3 节 )。 令 人 遗憾 的 是 ，anyof() 的 语法 有 些 诡异 。 首 先 ， 它 
会 接收 一 个 数组 〈 可 变 参 数 ) ， 不 管 底层 Future 是 什么 类 型 (比如 Flight)， 它 始终 会 返回 
CompLetabLeFuture<0bject>。 我 们 可 以 使 用 它 ， 但 是 代码 会 变 得 相当 杂乱 ， 如 下 所 示 。 
.thenCombine(location, (User us, GeoLocation Loc) -> { 


List<CompletableFuture<Flight>> fs = agencies 
.Stream() 
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.map(agency -> agency.searchAsync(us，Loc)) 
.collect(toList()); 
CompletableFuture[] fsArr = new CompLetabLeFuture[fs.size()]; 
fs.toArray(futuresArr); 
return CompletableFuture 
.anyOf(futuresArr) 
.thenAppLy(x -> ((Flight) x)); 
}) 


接 下 来 介绍 一 下 Stream.reduce() 的 技巧 。CompletableFuture.applyToEither() 操作 符 接 
收 两 个 CompLetabLeFuture， 并 将 给 定 的 转换 函数 应 用 到 第 一 个 完成 的 CompletableFuture 
上 。 如 果 你 有 两 个 同 种 类 型 的 任务 ， 并 且 只 关心 第 一 个 完成 的 ， 那 么 applyToEither() 转 
在 下 面 的 样 例 中 ， 我 们 在 两 个 服务 器 上 查询 User: 主 服 务 器 和 备用 服 

。 不 管 哪个 率先 完成 ， 样 例 都 会 使 用 一 个 简单 的 转换 ， ee 
ee We ea 的 执行 不 会 中 断 ， 但 是 结果 会 被 忽略 。 显 然 ， 最 后 得 到 的 是 
CompLetabLeFuture<LocaLDate>。 









































CompLetabLeFuture<User> primaryFuture = //.. 
CompLetabLeFuture<User> secondaryFuture = J... 


CompletableFuture<LocalDate> ageFuture = 
primaryFuture 
.applyToEither(secondaryFuture, 
User -> user.getBirth()); 


SpPly oR ther 只 能 与 两 个 CompletableFuture 组 合 使 用 ， 而 看 上 去 有 点 怪异 的 anyof() 
能 够 接收 任意 数量 的 CompletableFuture。 地 而 ， 还 可 以 使 用 前 两 个 Future 来 调用 
re 然后 将 得 到 的 结果 (前 两 个 中 较 快 的 一 个 ) 应 用 到 第 三 个 上 游 Future 
中 (从 而 得 到 前 三 个 中 最 快 的 一 个 )。 通 过 递归 调用 applyToEither()， 我 们 能 够 得 到 整体 
最 快 的 CompletableFuture。 这 个 便利 的 技巧 可 以 通过 reduce() 操作 符 来 实现 。 最 后 一 个 
提示 是 Function 中 的 identity() 方 法， 这 是 applyToEither() 需要 的 ， 我 们 必须 提供 一 
个 转换 功能 来 处 理 得 到 的 第 一 个 结果 。 如 果 想 要 原样 保留 结果 ， 那 么 可 以 使 用 一 个 恒 等 国 
数 ， 写 成 f -> f 或 (Flight f) -> f 的 形式 。 


终 实现 的 CompletableFuture<Flight> 会 在 最 快 的 TravelAgency 响应 时 完成 ， 这 个 过 程 
是 异步 进行 的。 thenCombine() 的 结果 还 有 点 小 问题 。 不 管 传递 给 thenCombine() 的 转换 
内 容 是 什么 ， 返回 的 结果 都 会 包装 在 一 个 CompletableFuture 中 。 我 们 的 场景 中 返回 的 
是 ee es 所 以 thenCombine() 的 结果 类 型 就 是 CompletableFuture 
<CompletableFuture<Flight>>。 在 使 用 0bservable 的 上 时候， 双重 包装 也 是 很 常见 的 问题 ， 
可 以 使 用 相同 的 技巧 来 应 对 这 两 种 情况 : flatMap()! (参见 3.1.2 节 )。 但 是 ， 就 像 map() 
在 Future 中 被 称 为 thenApply() 一 样 ，flatMap() 也 被 称 为 thenCompose() 。 


Observable<Observable<String>> badStream = //... 
Observable<String> goodStream = badStream.flatMap(x -> x); 












































CompletableFuture<CompletableFuture<String>> badFuture = //... 
CompletableFuture<String> goodFuture = badFuture.thenCompose(x -> x); 


我 们 通常 使 用 fLatMap()/thenCompose() 来 链接 异步 计算 ,但 是 这 里 只 是 简单 地 用 来 拆 解 不 
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正确 的 类 型 。 需 要 注意 ，thenCompose() 运行 给 定 的 转换 会 返回 CompletableFuture 类 型 。 
但 是 ， 因 为 内 部 类 型 已 经 是 Future 了 ， 样 例 可 以 使 用 identity() 或 简单 的 x -> x， 拆 解 
内 部 的 Future 以 修正 类 型 的 问题 。 

最 后 得 到 了 CompletableFuture<Flight> (缩写 为 flightFuture)。 接 下 来 ， 样 例 就 可 以 调 
用 bookAsync() 了 ， 它 以 Flight 作为 参数 。 


CompletableFuture<Ticket> ticketFuture = flightFuture 
.thenCompose(flight -> bookAsync(flight)); 


样 例 在 调用 bookAsync() 时 ， 使 用 thenCompose() 就 更 加 自然 了 。 这 个 方法 返回 的 是 
CompLetabLeFuture<Ticket>， 为 了 避免 双重 包装 ， 我 们 选择 使 用 thenCompose()， 而 不 是 
thenApply( )。 


























5.4.2 ”与 CompletableFuture 进 行 交 互 


返回 0Observable<T> 的 工厂 方法 0bservable.from(Future<T>) 已 经 存在 了 。 但 是 ， 由 于 旧 
有 Future<T> API 的 限制 ， 它 有 一 些 缺 点 ， 甚 中 最 大 的 缺点 就 是 Future.get() 内 部 是 阻塞 
的 。 传 统 的 Future<T> 实现 没有 办 法 注册 回调 并 以 异步 的 方式 进行 处 理 ， 因 此 在 反应 式 应 
用 程序 中 ， 它 们 并 没有 太 大 的 用 处 。 


CompletableFuture 则 与 之 完全 不 同 。 在 语义 上 讲 ， 可 以 将 CompletableFuture 视 为 具有 如 
下 特征 的 Observable。 


口 它 是 hot 类 型 的 。 
CompletableFuture 的 后 台 计 算是 立即 启动 的 ， 无 论 是 否 有 人 注册 thenApply() 这 样 的 
回调 。 


口 它 的 结果 是 缓存 的 。 
CompletableFuture 的 后 台 计 算 会 立即 触发 ， 得 到 的 结果 会 被 转发 至 所 有 注册 的 回调 。 
除 此 之 外 ， 如 果 有 的 回调 是 在 CompletableFuture 完成 之 后 广 册 的 ， 这 个 回调 会 立即 基 
于 完成 时 的 值 (或 异常 ) 进行 调用 。 

口 它 只 能 发 布 一 个 值 或 异常 。 
理论 上 ，Future<T> 只 能 完成 一 次 (或 者 永远 不 进入 完成 状态 )， 并 且 带 有 TT 类 型 的 返回 
值 或 异常 。 这 符合 Observable 的 契约 。 


1. 将 CompletableFuture 转 换 成 只 有 一 个 元 素 的 0bservable 
首先 编写 一 个 工具 函数 ， 这 个 函数 接收 CompletableFuture<T> 并 返回 一 个 正常 的 Observable<T>。 


class Util { 
static <T> Observable<T> observe(CompletableFuture<T> future) { 
return Observable.create(subscriber -> { 
future.whenComplete((value, exception) -> { 

if (exception != nuLL) { 
subscriber .onError(exception); 

} else { 
subscriber .onNext(value); 
subscriber .onCompleted(); 
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为 了 同时 能 够 得 到 成 功 和 失败 的 完成 通知 ， 这 里 使 用 了 CompletableFuture.whenComplete() 
方法 ， 它 接收 两 个 相互 排斥 的 参数 。 如 果 exception 不 为 空 ， 就 代表 底层 的 Future 失败 
了 ; 否则 ， 样 例 就 能 得 到 成 功 的 value 值 。 这 两 种 情况 都 会 通知 传人 的 subscriber。 需 要 
注意 ， 如 果 订 阅 是 〈 以 某 种 方式 ) 在 CompletableFuture 完成 之 后 才 出 现 的 ， 那 么 回调 将 
会 立即 执行 。CompletableFuture 会 缓存 完成 时 的 结果 ， 所 以 在 此 之 后 注册 的 回调 会 立即 在 
客户 端 线程 中 执行 。 

很 容易 会 想到 注册 一 个 取消 订阅 处 理 器 ， 在 取消 订阅 的 同时 ， 取 消 对 CompletableFuture 
的 执行 。 

// 不 要 这 样 做 


subscriber .add(Subscriptions.create( 
() -> future.cancel(true))); 


这 是 一 个 很 糟糕 的 主意 。 基 于 一 个 CompletableFuture 可 以 创建 很 多 0bservable， 而 每 个 
Observable 可 能 又 会 有 多 个 Subscriber。 如 果 有 一 个 Subscriber 在 Future 完成 之 前 取消 
执行 ， 将 会 影响 到 其 他 所 有 的 Subscriber。 

需要 记 住 ， 按 照 Rx 的 语义 ，ComptetabLeFuture 是 hot 类 型 的 ， 并 且 会 进行 缓存 。 
CompletableFuture 会 立即 进行 计算 ， 而 0bservable 只 在 有 人 订阅 的 时 候 才 会 开始 计算 。 
下 面 的 小 工具 可 以 进一步 优化 API。 


Observable<User> rxFindById(long id) { 
return Util.observe(findByIdAsync(id)); 


























} 


Observable<GeoLocation> rxLocate() { 
return Util.observe(locateAsync()); 


} 


Observable<Ticket> rxBook(Flight flight) { 
return Util.observe(bookAsync(flight)); 
} 


显然 ， 如 果 你 消费 的 API 从 一 开始 就 支持 Observable， 那 么 就 没有 必要 使 用 这 些 额 外 的 适 

配器 层 了 。 但 是 ， 如 果 有 具备 的 只 是 CompletableFuture， 将 它们 转换 成 Observable 才 是 高 

效 和 安全 的 。RxJava 的 优势 在 于 它 能 够 以 更 加 简洁 的 方式 解决 最 初 的 问题 。 
Observable<TravelAgency> agencies = agencies(); 


Observable<User> user = rxFindById(id); 
Observable<GeoLocation> location = rxLocate(); 




















Observable<Ticket> ticket = user 
.ZipWith(location, (us, loc) -> 
agencies 
.flatMap(agency -> agency.rxSearch(us, loc)) 
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.first() 


) 
.flatMap(x -> x) 
.flatMap(this: :rxBook); 


使 用 RxJava API 的 客户 端 代码 看 上 去 更 简洁 ， 也 更 易 读 。Rx 原生 地 支持 流 形式 的 “ 带 有 
多 个 值 的 future"。 如 果 你 还 是 觉得 flatap() 中 的 恒 等 转 换 x -> x 有 些 烦琐 ， 可 以 结合 
Pair 辅助 容器 对 zipwith() 进行 切 分 ， 如 下 所 示 。 


import org.apache.commons.Lang3.tupLe.Pair; 








Vy A 
Observable<Ticket> ticket = user 
.ZipWith(location, (usr, loc) -> Pair.of(usr, loc)) 
.flatMap(pair -> agencies 
.flatMap(agency -> { 
User usr = pair.getLeft(); 
GeoLocation loc = pair.getRight(); 
return agency.rxSearch(usr, loc); 


})) 
.first() 
.flatMap(this: :rxBook); 


此 时 ， 你 应 该 能 够 理解 为 何不 需要 额外 的 x -> x。zipwith() 会 接收 两 个 独立 的 0bservable， 
并 异步 等 待 它们 。Java 没有 内 置 的 配对 和 元 组 类 ， 所 以 这 里 必须 要 提供 一 个 转换 函数 ， 用 来 
接收 两 个 流 中 的 事件 并 将 它们 组 合成 一 个 0Observable<Pair<User，Location>> 对 象 。 这 个 对 
象 将 会 作为 下 游 0bservablte 的 输入 。 随 后 ， 根 据 给 定 的 User 和 Location， 使 用 flatMap() 
并 发 查询 每 个 旅行 社 。flatMap() 会 拆 解 结果 (从 语法 角度 来 说 )， 所 以 最 终 形成 的 流 就 是 
一 个 简单 的 Observable<Flight>。 这 两 种 情况 都 会 调用 first()， 但 是 样 例 只 处 理 上 游 流 中 
第 一 个 出 现 的 Flight (最 快 的 TravelAgency)。 
2. 从 Observable 到 CompletableFuture 
在 有 些 情况 下 ， 你 使 用 的 API 可 能 支持 CompletableFuture， 但 是 不 支持 RxJava。 这 很 常 
见 ， 尤 其 是 考虑 到 前 者 是 JDK 的 一 部 分 ， 而 后 者 只 是 一 个 库 。 在 这 样 的 情况 下 ， 如 果 能 够 
将 observablte 转换 成 CompletableFuture， 那 是 非常 棒 的 ， 以 下 两 种 方式 能 够 实现 这 样 的 
转换 。 
口 Observable<T> 到 CompLetabLeFuture<T> 
预期 在 流 中 发 布 一 个 条 目 时 使 用 它 ， 比 如 Rx 包装 一 个 方法 调用 或 者 请 求 /响应 模式 。 
如 果 流 完成 的 时 候 只 发 布 了 一 个 值 ， 那 么 CompletableFuture<T> 也 会 成 功 完成 。 显 然 ， 
如 果 流 出 现 异常 或 者 完成 时 发 布 的 值 不 是 一 个 ， 那 么 future 将 会 以 异常 的 状态 完成 。 
口 Observable<T> 到 CompletableFuture<List<T>> 
在 这 种 场景 下 ， 上 游 observable 的 值 都 已 发 布 并 且 流 完成 的 时 候 ，CompletableFuture 
会 完成 。 这 只 是 上 一 个 转换 的 一 种 特殊 形式 。 
使 用 下 面 的 工具 方法 ， 可 以 很 容易 地 实现 第 一 个 场景 。 


static <T> CompLetabLeFuture<T> toFuture(Observable<T> observable) { 
CompletableFuture<T> promise = new CompletableFuture<>(); 
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observable 
.Single() 
.Subscribe( 
promise: :complete, 
promise: :completeExceptionally 
); 
return promise; 


} 


在 深入 讲解 实现 细节 之 前 ， 需 要 注意 这 个 转换 有 一 个 很 重要 的 副作用 : 它 会 订阅 
Observable， 因 此 会 强制 cold 类 型 的 0bservable 进行 评估 和 计算 。 另 外 ， 对 这 个 转换 的 每 
次 调用 都 会 再 次 进行 订阅 ， 这 只 是 你 需要 注意 的 一 个 设计 选择 。 

除 此 之 外 ， 功 能 实现 本 身 是 非常 有 意思 的 。 首 先 ， 使 用 single() 强制 Observable 只 发 
布 一 个 元 素 ， 否 则 将 会 抛 出 异常 。 如 果 这 个 流 在 发 布 完 一 个 值 之 后 就 完成 ， 我 们 就 调用 
CompletableFuture.complete() 方法 。 事 实证 明 ， 可 以 从 头 创建 CompletableFuture， 而 不 
需要 任何 的 后 台 线 程 和 异步 任务 。 它 依然 是 一 个 CompletableFuture， 但 是 实现 完成 并 通知 
所 有 已 注册 回调 的 唯一 方法 是 显 式 调用 complete()。 这 是 一 种 异步 交换 数据 的 有 效 方法 ， 
至 少 在 RxJava 不 可 用 的 时 候 是 这 样 的 。 


如 果 出 现 失 败 ， 我 们 可 以 通过 调用 CompletableFuture.completeExceptionally() 触发 所 有 
已 注册 回调 的 错误 处 理 功 能 。 你 可 能 觉得 有 点 意外 ， 这 就 是 完整 的 实现 。toFuture 返回 的 
Future 看 上 去 似乎 有 与 其 关联 的 后 台 任 务 ， 但 实际 上 我 们 会 显 式 地 完成 它 。 

从 0bservable<T> 到 CompletableFuture<List<T>> 的 转换 非常 简单 。 






























































static <T> CompletableFuture<List<T>> toFutureList(Observable<T> observable) { 
return toFuture(observable.toList()); 


} 


CompletableFuture 和 0bservable 的 交互 是 非常 有 用 的 。 前 者 的 设计 非常 好 ， 但 是 缺 
乏 后 者 的 表述 性 和 功能 丰富 性 。 因 此 ， 如 果 必 须要 在 基于 RxJava 中 的 应 用 程序 中 处 理 
CompletableFuture， 那 么 可 以 尽早 使 用 这 些 简单 的 转换 功能 ， 以 提供 一 致 和 可 预测 的 API。 
请 确保 你 理解 了 Future 立即 执行 (hot) 和 0bservable 默认 延迟 执行 的 区 别 。 





5.5 Observable 与 Single 


经 常 看 到 有 人 害怕 使 用 RxJava， 原 因 在 于 它 看 上 去 过 于 以 流 为 中 心 。0bservable 是 一 个 流 ， 
其 至 可 能 是 无 穷 流 ， 而 且 所 有 的 操作 符 都 用 流 的 术语 进行 描述 。List<T> 可 能 只 包含 一 个 
元 素 ， 与 之 类 似 ， 有 些 0bservable<T> 按照 定义 只 能 发 布 一 个 事件 。 如 果 List<T> 始终 只 包 
含 一 个 元 素 ， 会 让 人 感觉 非常 困惑 ， 所 以 这 种 场景 下 可 以 简单 地 使 用 T 或 0ptionaL<T>。 在 
RxJava 领域 ， 有 一 个 针对 仅 发 布 一 个 事件 的 Observable 抽象 ， 它 就 是 rx.Single<T>。 


single<T> 基本 上 是 一 个 容器 ， 包 含 了 一 个 未 来 会 出 现 的 T 类 型 的 值 或 Exception。 就 这 
方面 ，Java 8 中 的 CompletableFuture 可 以 说 是 Single 的 近亲 (参见 5.4 节 )。 但 是 ， 与 
CompletableFuture 不 同 ，Singte 是 延迟 执行 的 ， 只 有 有 人 实际 订阅 的 时 候 才 会 生成 值 。 
Singte 主要 用 于 异步 返回 单个 值 (duh!) 并 具有 高 失败 概率 的 API。 显 然 ， 在 涉及 IO 通 
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信 的 请 求 - 响应 类 型 场景 中 (如 网 络 调用 )，single 是 一 个 很 好 的 替代 方案 。 相 对 于 正常 
的 网 络 调 用 ， 延 迟 一 般 会 非常 高 ， 失 败 也 是 难以 避免 的 。 另 外 ， 因 为 single 是 延迟 执行 并 
且 是 异步 的 ， 比如 并 发 调用 独立 的 操作 并 将 结果 组 
合 在 一 起 (参见 5.5.2 节 )。Single 通过 类 型 级 别 的 提示 ， 减 轻 了 API 返回 0bservablte 带 
来 的 困惑 。 


Observable<Float> temperature() { 


ls 











} 
我 们 很 难 预 测 上 面 方法 的 掉 约 。 只 返回 一 个 温度 值 就 完成 吗 ? 还 是 返回 温度 值 形成 的 
一 个 无 穷 流 ? 甚至 更 糟糕 ， 在 某 些 场景 下 ， 它 可 能 不 发 布 任何 事件 就 完成 了 。 如 果 
temperature() 返回 Single<Float>， 我 们 马上 就 能 知道 预期 的 输出 是 什么 。 









































5.5.1 创建 和 消费 single 

在 支持 的 操作 符 方面 ，Single 与 Observable 非常 相似 ， 所 以 我 们 不 会 在 这 方面 花费 太 多 
时 间 。 而 是 将 Single 的 操作 符 和 0bservable 对 应 的 操作 符 进行 简单 对 比 ， 并 且 主 要 关注 
Singlte 的 用 例 。 创 建 Single 的 方式 很 少 ， 让 我 们 从 常量 形式 的 just() 和 error() 操作 符 
开始 。 


import rx.Single; 















































Single<String> single = Single.just("Hello, world!"); 
single.subscribe(System.out::println); 


Single<Instant> error = 
Single.error(new RuntimeException("Opps!")); 
error 
.observeOn(Schedulers.io()) 
.Subscribe( 
System.out::println, 
Throwable: :printStackTrace 
); 
just() 操作 符 没 有 接收 多 个 值 的 重 载 版 本 ， Single 只 能 持 有 一 个 值 。 同 
时 ，subscribe() 方法 会 接收 两 个 参数 ， 而 不 是 三 个 ， 因 为 它 没有 必要 再 有 onComplete() 
回调 了 。single 在 完成 的 时 候 要 么 会 有 一 个 值 (第 一 个 回调 )， 要 么 会 出 现 异常 (第 二 
个 回调 )。 仅 仅 监听 完成 通知 等 价 于 订阅 单个 值 。 除 此 之 外 ， 这 里 还 包含 了 observeon() 
操作 符 ， 它 的 运行 方式 和 ee 对 应 的 操作 符 是 完全 相同 的 。 同 样 的 情况 也 适用 于 
subscribe0n() (参见 4.5 节 )。 最 后 ， 你 可 以 使 用 error() 操作 符 来 创建 Single， 它 始终 会 
以 给 定 Exception 的 形式 完成 。 


接 下 来 实现 一 个 更 加 现实 的 场景 ， 也 就 是 发 送 HTTP 请 求 。5.2 节 介 绍 了 如 何 使 用 RxNetty 
构建 异步 的 HTTP 客户 端 。 这 次 我 们 要 使 用 async-http-client， 它 也 在 底层 使 用 了 Netty。 
发 送 HTTP 请 求 之 后 ， 样 例 可 以 提供 一 个 回调 实现 ， 这 个 回调 会 在 请 求 得 到 响应 或 出 现 错 
误 时 异步 调用 。 这 种 场景 非常 符合 创建 Single。 
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import com.ning.http.client.AsyncCompletionHandler; 
import com.ning.http.client.AsyncHttpClient; 
import com.ning.http.client.Response; 


AsyncHttpClient asyncHttpCLient = new AsyncHttpClient(); 


Single<Response> fetch(String address) { 
return Single.create(subscriber -> 
asyncHttpClient 
.prepareGet(address) 
.execute(handler(subscriber))); 


} 


AsyncCompletionHandler handler(SingleSubscriber<? super Response> subscriber) { 
return new AsyncCompletionHandler() { 
public Response onCompleted(Response response) { 
subscriber .onSuccess(response); 
return response; 


} 


public void onThrowable(Throwable t) { 
subscriber .onError(t); 


} 
}; 

} 
Single.create() 与 Observable.create() (参见 2.4.1 节 ) 非常 类 似 ， 但 是 它 有 一 个 非常 
重要 的 限制 : 调用 onSuccess() 或 者 onError() 的 机 会 只 有 一 次 。 从 技术 上 ， 样 例 可 以 创 
建 一 个 永 不 完成 的 Singte， 但 是 不 允许 多 次 调用 onSuccess()。 除 了 Singte.create() 之 
外 ， 你 还 可 以 尝试 一 下 Single.fromCallable()， 后 者 能 够 接收 一 个 Callable<T> 并 返回 
single<T>。 这 同样 非常 简单 。 
回 到 HTTP 客户 端的 样 例 。 响 应 返回 的 时 候 ， 样 例会 通过 调用 onsuccess() 告知 订阅 者 ， 
或 者 在 异步 失败 回调 中 通过 onError() 传递 异常 。 可 以 采用 与 Observable 类 似 的 方式 来 使 
用 single。 如 下 所 示 。 

Single<String> example = 


fetch("http://www.example.com") 
.flatMap(this: :body); 























String b = example.toBlocking().value(); 


1... 


Single<String> body(Response response) { 
return Single.create(subscriber -> { 
try { 
subscriber .onSuccess(response.getResponseBody()); 
} catch (IOException e) { 
subscriber .onError(e); 





} 
// 与 body() 的 功能 相同 


Single<String> body2(Response response) { 
return Single.fromCallable(() -> 
response.getResponseBody() ) ; 


} 


比较 遗憾 的 是 ，Response.getResponseBody() 可 能 会 抛 出 I0Exception， 所 以 不 能 简单 地 使 
用 map(Response: :getResponseBody)。 但 至 少 我 们 在 这 里 看 到 了 Single.flatMap() 是 如 何 
运行 的 。 将 有 潜在 危险 的 getResponseBody() 方法 用 Single<sString> 包装 之 后 ， 就 能 确保 
潜在 的 失败 会 封装 起 来 ， 并 在 类 型 系统 中 清晰 地 进行 表述 。 在 了 解 Observable.flatMap() 
之 后 ，Single.flatMap() 的 运行 方式 和 预期 是 一 样 的 ; 如 果 第 二 个 阶段 的 计算 (在 本 例 中 
是 this::body) 失败 ， 整 个 Single 也 会 失败 。 有 意思 的 是 ，Single 有 map() 和 flatMap() 
操作 符 ， 但 是 没有 filter() 操作 符 。 你 能 猜 到 为 什么 吗 ? 原理 上 ，fitter() 可 能 过 滤 掉 
single<T> 中 不 满足 给 定 Predicate<T> 的 内 容 。Single<T> 内 部 必须 有 且 仅 有 一 个 条 目 ， 而 
filter() 有 可 能 会 导致 Singte 内 部 一 无 所 有 。 


与 BlockingObservable (参见 4.2 节 ) 类 似 ，Single 有 自己 的 BLockingSsingte， 可 以 通过 
Single.toBlocking() 来 创建 。 类 似 地 ， 创 建 Blockingsingle<T> 并 不 会 阻塞 。 但 是 样 例 调 
用 value() 会 阻塞 ， 直 到 类 型 为 7 (在 本 例 中 是 包含 响应 的 String) 的 值 可 用 。 如 果 出 现 
异常 ， 它 会 从 value() 方法 中 重新 抛 出 。 


5.5.2 ”使 用 zip、merge 和 concat 组 合 响 应 


如 果 没 有 可 组 合 的 操作 符 ， 那 么 rx.single 不 会 有 太 大 的 用 处 。 你 遇 到 的 最 重要 的 操作 符 
可 能 就 是 Single.zip()， 它 的 运行 方式 和 0bservable.zip() 完全 相同 (参见 3.2.1 节 ), 但 
是 语义 更 简单 。Ssingle 始终 只 会 发 布 一 个 值 (或 异常 )， 所 以 Single.zip() (或 实例 版 
本 的 single.zipWith() 方法) 的 结果 只 会 有 一 个 配对 /元 组 。zip() 基本 上 就 是 底层 两 个 
single 都 完成 的 时 候 ， 创 建 第 三 个 single 的 一 种 方法 。? 

假设 要 在 网 站 上 泻 染 一 篇 文章 。 满 足 这 个 请 求 需要 三 个 独立 的 操作 ， 从 数据 库 读 取 文 章 内 
容 ， 请 求 社交 媒体 网 站 ， 收 集 到 目前 为 止 的 点 赞 人 数 ， 更 新 文章 阅读 数量 指标 。 原 生 实现 
不 仅 会 序列 化 地 执行 这 三 个 操作 ， 如 果 某 个 步骤 非常 慢 ， 还 有 可 能 导致 无 法 接受 的 延迟 。 
借助 Singte， 可 以 对 每 个 步骤 分 别 建 模 ， 如 下 所 示 。 


import org.springframework.jdbc.core.JdbcTemplate; 


































































































11... 


Single<String> content(int id) { 
return Single.fromCallable(() -> jdbcTemplate 
.queryForObject( 
"SELECT content FROM articles WHERE id = ?"， 
String.class, id)) 





注 2: 在 CompletableFututre 中 ， 这 个 操作 符 为 thenCombine。 
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.SubscribeOn(Schedulers.io()); 


} 


Single<Integer> likes(int id) { 
// 对 社交 媒体 Web 站 点 的 异步 HTTP 请 求 


Single<Void> updateReadCount() { 
//single 只 有 副作用 ,没有 返回 值 











这 个 样 例 展示 了 如 何 使 用 fromCallable 创建 single， 其 中 ，fromCallable 通过 lambda 表 
达 式 传递 。 这 个 工具 是 非常 有 用 的 ， 它 管理 着 错误 处 理 功 能 (参见 7.1.1 节 )。content() 
方法 使 用 了 Spring 框架 提供 的 JdbcTemplate 工具 ， 以 便 从 数据 库 中 隐蔽 地 加 载 文章 内 容 。 
JDBC 本 质 上 会 阻塞 API， 所 以 样 例 显 式 调 用 了 subscribeon()， 让 single 变 成 异步 的 。 样 
例 省 略 了 Likes() 和 updateReadCount() 的 实现 。 你 可 以 将 likes() 设想 为 通过 RxNetty 
(参见 5.2 节 ) 向 特定 的 API 发 送 异 步 HTTP 请 求 。updateReadCount() 比较 有 意思 ， 它 的 
类 型 是 Singte<votd>。 这 表明 它 会 执行 一 些 没 有 返回 值 的 副作用 ， 但 是 这 个 操作 会 有 明显 
的 延迟 。 不 过 ， 我 们 依然 想 要 在 异步 发 生 可 能 的 失败 时 得 到 通知 。 针 对 这 种 情况 ，RxJava 
也 有 一 个 专门 的 类 型 ， Completable。 它 会 列 明 是 正常 完成 而 没有 结果 ， 还 是 异步 地 产生 了 
异常 。 
将 这 三 个 操作 通过 zip 组 合 起 来 就 非常 简单 了 。 
Single<Document> doc = Single.zip( 
Content(123 ) ， 
likes(123), 


UpdateReadCount() ， 
(con, lks, vod) -> buildHtml(con, lks) 





























); 
a 


Document buildHtml(String content, int likes) { 
1 
} 


Single.zip() 会 接收 三 个 single ( 它 有 接收 两 个 到 九 个 实例 的 重 载 版 本 )， 三 个 single 
都 完成 的 时 候 ， 就 会 执行 自 定义 的 函数 。 这 个 自 定义 函数 的 输出 会 放 回 到 一 个 
Single<Document> 中 ， 样 例 可 以 对 它 进行 进一步 的 转换 。 你 应 该 注意 到 Void 结果 没有 在 转 
换 过 程 中 使 用 ， 这 意味 着 样 例 需 要 等 待 updateReadCount() 完成 ， 但 是 并 不 需要 它 的 结果 
(为 空 )。 这 可 能 是 一 种 需求 ， 也 可 能 是 潜在 的 优化 点 如 果 updateReadCount() 异步 执行 ， 
而 不 等 待 它 正常 完成 或 出 现 失败 ， 那 么 构建 HTML 文档 的 功能 依然 能 够 很 好 地 运行 。 

现在 假设 一 下 ， 如 果 调 用 tikes() 出 现 了 失败 ， 或 者 经 历 了 一 段 长 到 无 法 接受 的 时 间 才 完 
成 〈 后 者 会 更 糟糕 ) ， 会 出 现 什么 情况 呢 ? 如 果 不 采 用 Reactive Extensions 演 染 ，HTML 将 
会 完全 失败 或 者 经 历 相 当 长 的 时 间 。 但 是 ， 我 们 现在 的 实现 也 好 不 到 哪里 去 。Singte 支持 
多 个 像 timeout()、onErrorReturn() 和 onErrorResumeNext() 这 样 的 操作 符 ， 它 们 能 够 强化 
弹性 和 错误 处 理 的 相关 功能 。 这 些 操作 符 的 行为 与 0bservablte 对 应 的 操作 符 完全 一 样 。 
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5.5.3 与 Observable 和 CompletableFuture 的 交互 

从 类 型 系统 的 角度 ，0bservable 和 Singte 是 互 不 相关 的 。 这 基本 意味 着 ， 需 要 0bservable 
的 时 候 ， 我 们 不 能 使 用 Singte， 反 之 亦 然 。 但 是 在 以 下 两 种 场景 中 ， 它 们 之 间 的 转换 是 有 
意义 的 。 

。 使 用 single 作为 Observable， 只 发 布 一 个 值 和 完成 通知 (或 错误 通知 )。 

。 Single 缺少 0bservable 支持 的 操作 符 的 时 候 ，cache() 就 是 一 个 例子 。” 

本 节 以 第 二 个 原因 进行 举例 说 明 。 


Single<String> single = Single.create(subscriber -> { 
System.out.println("Subscribing"); 
subscriber .onSuccess("42"); 

















]); 

Single<String> cachedSingle = single 
.toObservable() 
.Cache() 
.toSingle(); 


cachedSingle.subscribe(System.out::println); 
cachedSingle.subscribe(System.out::println); 


这 里 使 用 了 cache() 操作 符 ， 这 样 Single 只 会 为 第 一 个 订阅 者 生成 42。Single.toObservable() 
是 一 个 非常 安全 和 易于 理解 的 操作 符 。 它 会 接收 一 个 single<T> 实例 ， 并 将 其 转换 为 
Observable<T>， 这 个 Observable 发 布 一 个 元 素 之 后 会 立即 发 送 完成 通知 (如果 符 合 
single 的 完成 方式 则 发 送 错误 通知 )。 与 之 相反 ，0bservablte.toSingte() (不 要 与 single() 
操作 符 混 消 ， 参 见 3.3.3 节 ) 则 更 加 需要 注意 。 与 single() 类 似 ， 如 果 底 层 Observable 发 布 
的 元 素 超出 了 一 个 ，toSingte() 将 会 抛 出 一 个 异常 ， 表 明 “0bservable 发 布 了 太 多 的 元 素 ”; 
如 果 0bservable 为 空 ， 预 期 结果 将 是 “0bservable 没有 发 布 任何 条 目 ”。 
Single<Integer> emptySingle = 
Observable.<Integer>empty().toSingle(); 


Single<Integer> doubleSingle = 
Observable.just(1, 2).toSingle(); 


你 可 能 认为 toobservable() 和 tosingte() 使 用 位 置 接近 的 时 候 ， 后 者 会 更 安全 ， 但 事实 可 
能 并 非 如 此 。 比 如 ， 中 间 的 0bservable 可 能 会 对 Singte 发 布 的 值 进行 重复 或 丢弃 。 
Single<Integer> ignored = Single 
.just(1) 
.toObservable() 


.ignoreElements() // 有 问题 的 
.toSingle(); 


在 上 面 的 代码 中 ，0bservable 中 的 ignoreElements() 会 丢弃 Single 发 布 的 单个 值 。 因 此 ， 


使 用 tosingle() 操作 符 的 时 候 ， 只 能 看 到 一 个 没有 任何 条 目 就 结束 的 bbservabte。 需 要 注 
意 ，toSingle() 和 之 前 看 到 的 其 他 操作 符 类 似 ， 都 是 延迟 执行 的 。 有 人 真正 订阅 的 时 候 ， 

























































































注 3: 截至 本 文 撰写 时 (RxJava 1.1.6)。 这 组 可 用 的 操作 符 更 新 得 很 快 ,请 确保 使 用 的 是 最 新 版 本 并 再 次 检查 。 
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才 会 出 现 Singte 不 能 精确 发 布 一 个 事件 的 异常 。 


5.5.4” 何 时 使 用 Single 


了 解 完 Observable 和 single 这 两 种 抽象 ， 识 别 它们 的 差异 并 理解 使 用 的 场景 就 非常 重 
要 了 。 就 像 数据 结构 一 样 ， 一 种 结构 不 能 放 之 四 海 缘 准 。 在 如 下 的 场景 中 ， 应 该 使 用 
Single, 


。 某 种 操作 必须 以 某 个 特定 值 或 异常 的 形式 完成 。 例 如 ， 调 用 Web 服务 ， 要 么 会 得 到 一 
个 来 自 外 部 服务 器 的 响应 ， 要 么 得 到 某 种 形式 的 异常 。 

。 在 你 的 问题 域 中 ， 并 没有 流 这 样 的 存在 ， 使 用 0bservable 会 造成 误导 和 大 材 小 用 。 

。 Observable 过 于 重量 级 ， 你 衡量 后 认为 Singte 在 某 个 特定 的 问题 中 更 快 。 

一 方面 ， 在 如 下 的 场景 中 优先 选择 0bservable。 

。 你 要 为 某 种 类 型 的 事件 (消息 、GUI 事件 ) 进行 建 模 ， 按 照 定义 ， 它 们 会 多 次 出 现 ， 甚 
至 是 无 穷 的 。 

。 或 者 完全 相反 ， 你 的 预期 是 : 值 在 完成 之 前 可 能 出 现 ， 也 可 能 不 出 现 。 

第 二 个 场景 是 非常 有 意思 的 。 你 是 否 会 认为 ， 针 对 某 些 存储 库 (repository) 中 的 FindByIdCint) 

方法 ， 使 用 Single<Record> 会 比 使 用 Record 或 Observable<Record> 更 合理 呢 ? 听 上 去 似 

乎 很 有 道理 : 我 们 根据 ID 获取 一 个 条 目 (这 说 明 这 样 的 Record 只 有 一 个 )。 但 是 ， 无 法 

确保 每 个 给 定 的 ID 都 一 定 存 在 这 样 一 个 Record。 因 此 ， 这 个 方法 有 可 能 不 返回 任何 内 容 。 

我 们 将 其 建 模 为 nuLL、0ptionaL<Record> 或 0bservabLe<Record>， 都 能 很 好 地 处 理 空 流 之 

后 紧 跟着 完成 通知 的 场景 。Singte 又 怎样 呢 ? 它 要 么 以 一 个 值 的 形式 (Record) 正常 完 

成 ， 要么 出 现 一 个 异常 。 如 果 你 想 将 条 目 不 存 在 建 模 为 异常 ， 这 是 你 的 设计 选择 ， 但 通常 

认为 这 是 一 种 精 糕 的 实践 。 判 断 一 条 给 定 ID 的 缺失 记录 是 否 是 真正 的 异常 场景 ， 不 应 该 

是 存储 库 层 的 责任 。 


5.6 小 结 


第 2 章 和 第 3 章 让 你 对 RxJava 有 了 一 个 整体 的 印象 和 感觉 。 本 章 讨论 了 设计 完整 反应 式 
应 用 程序 的 高 级 话题 。 这 部 分 是 更 高 级 的 内 容 ， 介 绍 了 实现 事件 驱动 系统 的 实际 技术 ， 而 
且 不 会 引入 额外 的 复杂 性 。 本 章 展现 了 一 些 测试 基准 ， 证 明 RxJava 与 非 阻塞 网 络 技术 栈 
(如 Netty) 组 合 带 来 的 性 能 优势 。 你 并 非 必 须要 使 用 这 些 高 级 的 库 ， 但 是 如 果 你 想 要 在 商 
业 服 务 器 上 实现 吞吐 量 最 大 化 ， 使 用 它们 肯定 会 物 有 所 值 。 















































HI 














































































































第 6 章 


流 控制 和 回 压 





托 马 什 : 努 尔 凯 维 茨 〈Tomasz Nurkiewicz) 


到 目前 为 止 ， 我 们 已 经 非常 熟悉 RxJava 基于 推送 的 特点 。 事 件 在 上 游 中 的 某 个 地 方 产 
生 ， 然 后 被 所 有 的 订阅 者 消费 。 我 们 一 直 没 有 关心 ， 如 果 0bserver 的 处 理 比 较 慢 ， 跟 不 上 
Observable.create() 的 事件 发 布 节奏 ， 会 导致 什么 后 果 。 本 章 会 就 这 个 问题 进行 讨论 。 
RxJava 有 以 下 两 种 方式 来 应 对 生产 者 比 订阅 者 更 活跃 的 情况 。 
。 各 种 流 控 制 机 制 ， 比 如 基于 内 置 的 操作 符 实现 采样 和 批 处 理 。 
。 订阅 者 通过 一 个 名 为 回 压 (backpressure) 的 反馈 通道 ， 来 传递 它们 的 需求 ， 并 且 只 请 
求 它 们 能 够 处 理 的 条 目 。 
本 章 将 会 介绍 这 两 种 机 制 。 


6.1 流 控制 


在 RxJava 实现 回 压 (参见 6.2 节 ) 之 前 ， 生 产 者 (0bservable) 的 生产 速度 超过 消费 者 
(Observer) 的 消费 速度 一 直 是 困扰 我 们 的 问题 。RxJava 发 明了 很 多 操作 符 来 处 理 生产 者 
推送 事件 太 多 的 情况 ， 它 们 中 的 大 多 数 本 身 就 非常 有 趣 。 有 些 用 于 事件 的 批 处 理 ， 有 些 则 
用 于 丢弃 一 些 事件 。 本 市 将 会 介绍 这 些 操作 符 ， 包 括 一 些 样 例 。 


6.1.1 定期 采样 和 节 流 
在 有 些 场景 下 ， 肯 定 想 要 接收 并 处 理 上 游 0bservable 推送 的 每 个 事件 。 但 是 ， 也 有 一 些 
场景 定期 采样 就 是 够 了 。 最 为 典型 的 场景 就 是 接收 某 个 设备 的 度量 数据 ， 比 如 温度 (对 
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比 3.3.4 市 )。 设 备 生成 新 度量 数据 的 频率 通常 与 我 们 无 关 ， 尤 其 是 当 度 量 数据 频繁 出 


现 ， 





而 且 彼此 非常 相似 的 时 候 。sampte() 操作 符 会 定期 (比如 ， 每 秒 一 次 ) 查看 上 游 的 























Observable， 并 将 遇 到 的 最 新 事件 发 布 出 来 。 如 果 在 过 去 的 一 秒 内 没有 事件 ， 则 不 会 对 下 
游 进 行 采样 。1 秒 之 后 ， 再 继续 下 一 次 的 采样 操作 ， 如 下 所 示 。 




















Long startTime = System.currentTimeMillis(); 
Observable 
.interval(7, TimeUnit.MILLISECONDS) 
.timestamp() 
.Sample(1, TimeUnit.SECONDS) 
.map(ts -> ts.getTimestampMillis() - startTime + "ms: " + ts.getValue()) 
.take(5) 
.Subscribe(System.out::printtLn); 





上 述 代 码 将 会 打印 出 类 似 下 面 的 输出 。 


第 一 











1088ms: 141 
2089ms: 284 
3090ms: 427 
4084ms: 569 
5085ms: 712 


列 展现 了 从 订阅 到 采样 发 布 的 相对 时 间 。 可 以 清晰 地 看 到 ， 第 一 次 采样 发 生 的 时 间 稍 








微 超出 了 1 秒 (作为 sample() 操作 符 的 要 求 )， 而 随后 的 采样 基本 都 是 间隔 1 秒 。 更 重要 
的 是 打印 出 的 值 。interval() 操作 符 从 零 开 始 每 7 毫秒 发 布 自然 数 。 因 此 ， 在 第 一 次 采样 
的 时 候 ， 预 计 会 出 现 142 (1000/7) 个 事件 ， 而 第 142 个 值 就 是 141 (从 零 开始 的 )。 

接 下 来 探讨 一 个 更 复杂 的 采样 样 例 。 假 设 有 一 个 人 名 的 列表 ， 它 们 会 在 固定 的 时 间 间 隔 之 
后 分 别 出 现 ， 如 下 所 示 。 


























Observable<String> names = Observable 
.just("Mary", "Patricia", "Linda", 
"Barbara", 
"Elizabeth", "Jennifer", "Maria", "Susan", 
"Margaret", "Dorothy"); 


Observable<Long> absoluteDelayMillis = Observable 
.just(0.1, 0.6, 0.9, 
并 5 
3.3，3.4，3.5，3.6， 
4.4, 4.8) 
.map(d -> (long)(d * 1_000)); 


Observable<String> delayedNames = names 
.ZipWith(absoluteDelayMillis, 
(n, d) -> Observable 
.just(n) 
.delay(d, MILLISECONDS)) 
.flatMap(o -> 0); 


delayedNames 
.sample(1, SECONDS) 
.Subscribe(System.out::println); 





首先 ， 样 例 构 建 了 一 个 人 名 的 序列 ， 然 后 是 一 个 绝对 延迟 (以 秒 为 单位 ， 随 后 映射 为 毫 
秒 ) 序列 。 使 用 zipwith() 操作 符 定义 特定 人 名 的 延迟 ， 比 如 Mary 会 在 订阅 后 间隔 100 
毫秒 出 现 ， 而 Dorothy 会 在 4.8 秒 之 后 出 现 。sample() 操作 符 会 阶段 性 地 (每 秒 ) 从 流 
中 获取 上 一 个 时 间 段 内 最 后 出 现 的 人 名 。 所 以 ， 第 一 秒 之 后 ， 样 例 通 过 printtn 打印 
出 Linda， 再 往 后 一 秒 打印 出 Barbara。 在 订阅 之 后 的 2000 到 3000 毫秒 之 间 ， 没 有 人 
名 出 现 ， 因 此 sample() 不 发 布 任何 内 容 。 在 Barbara 发 布 出 来 两 秒 后 就 会 看 到 Susan。 
sample() 会 转发 完成 通知 (以 及 错误 ) ， 并 且 丢 弃 最 后 一 个 周期 。 如 果 我 们 想 让 Dorothy 
出 现 ， 可 以 人 为 地 延迟 完成 通知 的 发 送 ， 如 下 所 示 。 


static <T> Observable<T> delayedCompletion() { 
return Observable.<T>empty().delay(1, SECONDS); 












































} 
a 


deLayedNames 
.CconcatWith(delayedCompletion()) 
.SampLe(1，SECONDS ) 
.Subscribe(System.out::println); 


sample() 有 一 个 更 高 级 的 变种 形式 ， 它 接受 0bservable 作为 参数 ， 而 不 是 一 个 固定 的 周 
期 。 这 里 的 第 二 个 Observable ( 即 采 样 器 ，sampler) 基本 上 决定 了 何 时 从 上 游 源 中 采样 : 
每 次 采样 器 发 布 任意 值 ， 就 会 采集 一 个 新 的 样本 (前提 是 自 上 次 采样 之 后 出 现 了 新 的 值 )。 
你 可 以 使 用 这 个 重 载 版 本 的 sample()， 以 动态 改变 采样 率 或 者 只 在 某 个 特定 的 时 间 点 进行 
采样 。 例 如 ， 在 帧 重 绘 或 者 键盘 按 下 时 ， 截 取 快 照 。 下 面 这 个 样 例 能 够 通过 interval() 操 
作 符 简单 模拟 固定 周期 。 

// 等 价 的 

obs.sampLe(1，SECONDS ) ; 

obs.sample(Observable.interval(1, SECONDS)); 


可 以 看 到 ，sample() 的 行为 有 一 些 很 微妙 的 地 方 。 与 其 依赖 于 文档 和 手工 验证 的 理解 ， 还 
不 如 进行 一 些 自动 化 测试 。7.2.1 市 将 会 讨论 对 时 间 敏 感 的 操作 符 ， 例 如 sample()。 


在 RxJava 中 ，sample() 有 一 个 别名 ， 即 throttleLast()。 与 之 对 应 的 还 有 throttleFirst() 
操作 符 ， 它 会 发 布 每 个 阶段 中 的 第 一 个 事件 。 所 以 ， 使 用 throttteFirst() 来 替换 
sample()， 预 期 会 得 到 如 下 的 结果 。 


Observable<String> names = Observable 
.just("Mary", "Patricia", "Linda", 
"Barbara", 
"Elizabeth", "Jennifer", "Maria", "Susan", 
"Margaret", "Dorothy"); 







































































Observable<Long> absoluteDelayMillis = Observable 
.just(0.1, 0.6, 0.9, 
1,1,; 
3.3; 3:4; 3.5, .3.6; 
4.4, 4.8) 
.map(d -> (long)(d * 1_000)); 
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Ls 


delayedNames 
.throttleFirst(1, SECONDS) 
.Subscribe(System.out::println); 


输出 如 下 所 示 。 


Mary 
Barbara 
Elizabeth 
Margaret 


与 sample() 类 似 ( 即 throttleLast())， 如 果 在 Barbara 和 Elizabeth 之 间 没 有 新 的 人 名 出 
现 ， 那 么 throttleFirst() 不 会 发 布 任何 的 事件 。 


6.1.2 ”将 事件 缓冲 至 列表 中 


在 RxJava 提供 的 内 置 操作 符 中 ， 缓 冲 和 窗口 移动 (moving window) 是 最 令 人 兴奋 的 。 它 
们 都 会 通过 一 个 窗口 (window) 遍历 整个 输入 流 ， 这 个 窗口 会 捕获 多 个 连续 的 元 素 并 推动 
流程 向 前 运行 。 男 一 方面 ， 它 们 允许 批 处 理 上 游 源 中 的 值 ， 从 而 实现 更 高 效 的 处 理 。 在 实 
践 中 ， 它 们 是 灵活 而 且 用 途 广 泛 的 工具 ， 可 以 在 运行 期 对 数据 进行 各 种 聚合 。 


buffer() 操作 符 会 将 一 批 事件 实时 聚合 到 一 个 List 中 。 但 是 ， 与 toList() 操作 符 不 同 ， 
buffer() 发 布 的 列表 会 对 随后 出 现 的 事件 进行 分 组 ， 而 不 是 将 所 有 的 事件 放 到 同一 个 列表 
中 (如 toList())。buffer() 最 简单 的 形式 就 是 将 上 游 observable 中 的 值 分 组 到 相同 大 小 
的 列表 中 。 
Observable 

.range(1, 7) //1, 2, 3, ...7 

.buffer(3) 

.Subscribe((List<Integer> list) -> { 

System.out.println(list); 


} 






























































); 


当然 ，subscribe(System.out::println) 也 可 以 正常 运行 ， 这 里 出 于 教学 的 目的 ， 保 留 了 
类 型 的 信息 。 下 面 的 输出 展示 了 buffer(3) 操作 符 发 布 的 三 个 事件 。 
[1，2，3] 


[4, 5, 6] 
[7] 


buffer() 会 不 断 接收 上 游 的 事件 ， 并 在 内 部 对 它们 进行 缓冲 (因此 得 名 )， 直 到 缓冲 区 的 
大 小 达到 3， 此 时 整个 缓冲 区 (List<Integer>) 会 被 推送 至 下 游 。 完 成 通知 出 现时 ， 如 果 
内 部 缓冲 区 不 为 空 (但 是 还 没有 达到 3)， 它 依然 会 被 推送 至 下 游 。 这 就 是 为 什么 上 面 输出 
的 最 后 一 行 是 只 包含 一 个 元 素 的 列表 。 

使 用 buffer(int) 操作 符 ， 可 以 将 细 粒 度 的 事件 替换 为 数量 更 少 但 规模 较 大 的 批 处 理 。 例 如 ， 
如 有 果 你 想 要 减少 数据 库 的 负载 ， 那 么 就 可 以 将 每 个 事件 单独 存储 的 方案 替换 为 批量 存储 。 



























































interface Repository { 
void store(Record record); 
void storeAll(List<Record> records); 


} 
Las 
Observable<Record> events = //... 


events 
.Subscribe(repository::store); 


//vs. 


events 
.buffer(10) 
.Subscribe(repository::storeAll); 


后 面 的 订阅 调用 了 Repository 中 的 storeALL， 一 次 性 保存 了 10 个 元 素 。 这 种 方式 可 能 会 
提高 应 用 程序 的 吞吐 量 。 


buffer() 有 很 多 的 重 载 变种 。buffer() 将 列表 推送 至 下 游 时 ， 一 个 稍微 复杂 的 版 本 允许 配 
置 内 部 缓冲 区 中 最 旧 值 的 丢弃 数量 。 这 听 起 来 非常 复杂 ， 用 更 基础 的 术语 就 是 : 它 实 现 了 
通过 指定 大 小 的 移动 窗口 来 查看 事件 流 。 
Observable 
.range(1, 7) 
.buffer(3, 1) 
.Subscribe(System.out: :println); 


这 样 ， 样 例 将 会 产生 多 个 重合 的 列表 。 





























[1, 2, 3] 
[2, 3, 4] 
[3, 4, 5] 
[4, 5, 6] 
[5, 6, 7] 
[6, 7] 
[7] 


如 果 想 要 计算 某 些 时 序数 据 的 移动 平均 值 (moving average) ， 那 么 我 们 可 以 使 用 buffer(N，1) 
变种 形式 。 如 下 的 样 例 代码 将 会 按照 正 态 分布 生 成 1000 个 随机 值 。 随 后 ， 取 一 个 100 个 
元 素 组 成 的 滑动 窗口 (每 次 前 进 一 个 元 素 ), 计算 这 个 窗口 的 平均 值 。' 亲自 运行 这 个 程序 ， 
并 观察 移动 平均 值 ， 你 会 发 现 它 比 随 机 无 序 值 要 平滑 得 多 。 


import java.util.Random; 
import java.util.stream.Collectors; 


/11... 


Random random = new Random(); 
Observable 
.defer(() -> just(random.nextGaussian())) 














注 1: 注意 这 不 是 最 高 效 的 算法 ， 因 为 该 算法 多 次 添加 相同 的 数字 。 
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.repeat(1000) 

.buffer(100, 1) 

.map(this: :averageOfList) 
.Subscribe(System.out::println); 


1... 


private double averageOfList(List<Double> list) { 
return list 
.Stream() 
.Collect(Collectors.averagingDouble(x -> x)); 


} 


你 可 以 将 buffer(N) 视 为 与 buffer(N，N) 等 价 。 最 简单 的 buffer() 形式 会 在 整个 缓冲 区 充 
满 之 后 丢弃 它 。 有 意思 的 是 ，buffer(int，iint) 的 第 二 个 参数 (用 来 指定 向 下 游 推送 时 要 
跳 过 元 素 的 数量 ) 可 以 大 于 第 一 个 参数 ， 这 实际 上 跳 过 了 一 些 元 素 ! 
Observable<List<Integer>> odd = Observable 
.range(1, 7) 


.buffer(1, 2); 
odd.subscribe(System.out::println); 


这 种 设置 会 转发 第 一 个 元 素 ， 但 随后 会 跳 过 两 个 元 素 ， 也 就 是 第 一 个 和 第 二 个 元 素 。 然 后 
循环 这 个 过 程 : buffer() 转发 第 三 个 元 素 ， 但 是 会 跳 过 的 第 三 个 和 第 四 个 元 素 。 它 的 输出 
将 会 是 : [1] [3] [5] [7]。 注 意 ，odd 0bservable 中 的 每 个 元 素 实际 上 都 是 一 个 单元 素 列 
表 。 可 以 使 用 flatMap() 或 flatMapIterable() 把 它 重新 变 成 Observable<Integer>。 
Observable<Integer> odd = Observable 
.range(1, 7) 


.buffer(1, 2) 
.flatMapIterable(list -> list); 


flatMapIterable() 预期 接收 一 个 函数 ， 该 函数 会 将 流 (由 单个 元 素 组 成 的 List<Integer>) 
中 的 每 个 元 素 转换 到 一 个 List 中 。 在 这 里 ， 恒 等 转换 (List -> list) 就 达到 要 求 了 。 


基于 时 间 阶段 进行 缓冲 

实际 上 ，buffer() 是 一 个 用 途 广泛 的 操作 符 家 族 。buffer() 的 另 一 个 变种 形式 能 够 根据 时 
间 阶 段 批量 处 理 上 游 的 事件 ， 而 不 是 根据 大 小 来 处 理 〈 在 这 种 情况 下 ， 每 个 批 次 的 事件 数 
量 是 相同 的 )。throttleFirst() 和 throttLeLast() 能 够 在 给 定时 间 段 内 分 别 获取 第 一 个 和 
最 后 一 个 元 素 ， 但 是 buffer 的 一 个 重 载 版 本 能 够 在 每 个 时 间 段 批量 处 理 所 有 的 事件 。 接 下 
来 回 到 人 名 样 例 。 


Observable<String> names = just( 
"Mary", "Patricia", "Linda", "Barbara", "Elizabeth", 
"Jennifer", "Maria", "Susan", "Margaret","Dorothy"); 
Observable<Long> absoluteDelays = just( 
0.1, 0.6, 0.9, 1.1, 3.3, 
3.4, 3.5, 3.6, 4.4, 4.8 
).map(d -> (long) (d * 1 000)); 









































Observable<String> delayedNames = Observable.zip(names, 
absoluteDelays, 





(n, d) -> just(n).delay(d, MILLISECONDS) 
).fLatMap(o -> 0o); 


deLayedNames 
.buffer(1, SECONDS) 
.Subscribe(System.out: :println); 


buffer() 的 重 载 版 本 接收 一 个 时 间 阶 段 (在 上 例 中 就 是 1 秒 ) ， 它 会 聚集 该 时 间 段 内 所 有 
的 上 游 事件 。 因 此 ，buffer() 会 收集 第 一 个 时 间 段 、 第 二 个 时 间 段 内 发 生 的 所 有 事件 ， 以 
此 类 推 。 

[Mary, Patricia, Lindal] 


[Barbara] 
[] 


[Elizabeth, Jennifer, Maria, Susan] 
[Margaret, Dorothy] 


第 三 个 List<String> 为 空 ， 因 为 在 这 个 时 间 段 内 没有 出 现 事 件 。buffer() 的 一 个 用 例 就 是 
统计 每 个 时 间 段 内 事件 的 数量 ， 如 计算 1 秒 内 关键 事件 的 数量 。 


Observable<KeyEvent> keyEvents = //... 

















Observable<Integer> eventPerSecond = keyEvents 
.buffer(1, SECONDS) 
.map(List::size); 


比较 好 的 一 点 是 ， 如 果 在 1 秒 内 没有 事件 ， 样 例 将 会 生成 一 个 空 的 列表 ， 这 样 ， 在 度量 中 
就 不 会 出 现 空白 。 但 是 ， 这 并 不 是 最 有 效 的 方式 ， 稍 后 将 会 介绍 window() 操作 符 。 


buffer() 方法 最 全 面 的 重 载 形 式 可 以 控制 该 操作 符 何 时 开始 缓冲 事件 ， 以 及 何 时 将 缓冲 区 
的 内 容 刷新 到 下 游 。 换 名 话说 ， 你 可 以 选择 在 哪个 时 间 段 对 上 游 的 事件 进行 分 组 。 假 设 你 
要 监控 一 些 频 繁 推送 遥测 数据 的 工业 设备 ， 这 种 场景 下 的 数据 量 会 非常 大 ， 为 了 市 省 计算 
能 力 ， 样 例 可 以 只 查看 特定 的 采样 数据 。 算 法 如 下 所 示 。 


。 在 业务 时 间 (9: 00 至 17: 00)， 每 秒 获取 100 毫秒 的 快照 (大约 处 理 10% 的 数据 )。 
。 在 业务 时 间 之 外 ， 每 5 秒 获取 200 毫秒 的 快照 (4%)。 


换 名 话说， 每 秒 (或 每 5 秒 ) 缓冲 100 毫秒 (或 者 相应 的 200 毫秒 ) 内 所 有 的 事件 ， 并 将 
这 个 时 间 段 内 的 所 有 事件 形成 的 列表 发 布 出 去 。 如 果 你 看 到 完整 的 例子 ， 就 会 更 加 清楚 
了 。 首 先 需 要 一 个 Observable， 开 始 进行 缓冲 (分 组 ) 上 游 事件 时 ， 它 能 随意 发 布 一 个 值 。 
这 个 0bservable 可 以 放 入 任何 类 型 的 值 ， 它 的 内 容 并 不 重要 ， 重 要 的 是 时 间 。 实 际 上 ， 返 回 
java.time 包 中 的 Duration 只 是 一 个 巧合 ，RxJava 并 没有 以 任何 形式 使 用 这 个 值 。 


Observable<Duration> insideBusinessHours = Observable 
.interval(1, SECONDS) 
.filter(x -> isBusinessHour()) 
.map(x -> Duration.ofMillis(100)); 
Observable<Duration> outsideBusinessHours = Observable 
.interval(5, SECONDS) 
.filter(x -> !isBusinessHour()) 
.map(x -> Duration.ofMillis(200)); 














x 
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Observable<Duration> openings = 0bservabLe.merge( 
insideBusinessHours, outsideBusinessHours); 


首先 ， 使 用 interval() 生成 按 秒 执行 的 计时 节拍 ， 不 过 这 里 排除 非 业 务 时 间 。 通 过 这 种 
方式 , 在 9: 00 和 17: 00 之 间 的 每 秒 生 成 了 一 个 稳定 的 时 钟 节拍 。 回 忆 一 下 interval() 
操作 符 ， 它 返回 的 是 不 断 递增 的 Long 类 型 自然 数 ， 但 是 ， 我 们 并 不 需要 这 样 的 值 ， 攻 
此 将 其 替换 成 了 109 毫秒 的 固定 间隔 。 与 之 完全 类 似 的 后 续 人 代码， 在 17: 00 和 9: 00 之 
间 每 5 秒 生成 一 个 值 的 稳定 流 。 如 果 你 关心 如 何 实现 isBusinessHour()， 其 实 它 用 到 了 
java.time 包 。 

































































private static final LocalTime BUSINESS_START = LocalTime.of(9, 0); 
private static final LocalTime BUSINESS_END = LocalTime.of(17, 0); 


private boolean isBusinessHour() { 
ZoneId zone = Zoneld.of("Europe/Warsaw"); 
ZonedDateTime zdt = ZonedDateTime.now(zone ) ; 
LocalTime LocaLTime = zdt.toLocalTime(); 
return !localTime.isBefore(BUSINESS_START) 
&& !localTime.isAfter(BUSINESS_END); 
} 


openings 流 会 将 insideBusinessHours 和 outsideBusinessHours 流 合并 (merge) 在 一 起 。 
它 基 本 上 就 是 一 个 定时 器 ， 指 示 buffer() 操作 符 何 时 从 上 游 中 采样 ， 而 不 是 将 其 丢弃 。 
openings 流 中 发 布什 么 样 的 值 完 全 没有 关系 。 但 是 ， 必 须 还 要 指定 何 时 停止 聚合 〈 缓 冲 ) 
事件 ， 并 将 其 以 一 个 List 的 形式 推送 至 下 游 。 最 显而易见 的 解决 方案 就 是 将 openings 流 
中 的 每 个 事件 作为 停止 当前 批 处 理 的 一 个 信号 ， 样 例 将 缓冲 的 事件 发 布 至 下 游 ， 并 开始 新 
的 批 处 理 。 


Observable<TeleData> Upstream = //... 






































Observable<List<TeleData>> samples = Upstream 
.buffer(openings ) ; 


注意 样 例 是 如 何 将 精心 设计 的 openings 传递 给 buffer() 操作 符 的 。 上 述 的 代码 片段 切 分 
了 由 TeleData 值 组 成 的 upstream。openings 流 的 时 钟 节拍 会 批量 处 理 来 自 upstrean 的 事 
件 。 在 业务 时 间 内 ， 每 秒 会 生成 一 个 批量 数据 ， 而 在 业务 时 间 之 外 ， 样 例会 按照 5 秒 一 组 
的 节奏 对 值 进行 批 量 分 组 。 在 这 个 版 本 中 有 一 点 很 重要 ， 来 自 upstrean 的 所 有 事件 都 会 
被 保留 下 来 ， 因 为 它们 要 么 属于 这 个 批 次 ， 要 么 属于 另外 一 个 批 次 。 不 过 ， 重 载 版 本 的 
buffer() 可 以 标记 某 个 批 处 理 何 时 结束 。 
Observable<List<TeleData>> samples = upstream 
.buffer( 
openings, 


duration -> empty() 
.delay(duration.toMillis(), MILLISECONDS)); 


























之 前 提 到 过 opentngs， 它 是 一 个 Observable<Duration>， 但 是 openings 流 中 的 事件 实际 值 
并 不 重要 。RxJava 只 是 使 用 这 个 事件 开始 缓冲 TeleData 实例 。 只 不 过 这 一 次 样 例 能 够 完 
全 控制 何 时 开始 缓冲 ， 以 及 何 时 将 缓冲 的 内 容 发 布 出 去 。 第 二 个 参数 是 一 个 Observable， 


























它 必须 在 我 们 想 要 停止 采样 的 时 候 完 成 。 第 二 个 流 的 完成 标志 着 给 定 批 次 的 结束 。 这 里 需 
要 仔细 观察 : 我 们 想 要 开始 一 个 新 的 批 次 时 ，openings 流 会 发 布 一 个 事件 。 对 于 openings 
发 布 的 每 个 事件 ， 样 例 都 会 返回 一 个 新 的 Observable， 它 应 该 在 未 来 的 某 个 时 间 点 完成 。 
例如 ，openings 发 布 一 个 值 为 Duation.ofMillis(100) 的 事件 时 ， 样 例 将 其 转换 为 一 个 
0bservable， 它 会 在 给 定 的 批 次 结束 时 完成 ， 在 这 里 也 就 是 100 毫秒 之 后 。 注 意 ， 在 连续 
的 批 次 中 ， 有 些 事件 可 能 会 被 丢弃 或 重复 出 现 。 如 果 第 二 个 Observable， 也 就 是 负责 标记 
给 定 批 次 完成 的 Observable， 出 现在 下 一 个 批 次 的 开始 事件 之 前 ， 那 么 在 这 个 时 间 差 之 内 
的 事件 将 会 被 buffer() 丢弃 。 具 体 到 这 里 : 每 秒 (在 业务 时 间 之 外 是 其 他 间隔 秒 数 ) 都 会 
缓冲 事件 ， 但 是 缓冲 区 会 在 100 毫秒 (或 者 200 毫秒 ， 视 情况 而 定 ) 之 后 关闭 ， 缓 冲 内 容 
会 被 转发 至 下 游 。 大 多 数 事件 都 会 落 在 缓冲 时 段 中 ， 因 此 会 被 丢弃 。 

buffer() 操作 符 非常 灵活 和 复杂 。 请 你 用 它 做 一 些 试验 性 的 尝试 并 确保 理解 了 上 述 样 例 。 
它 能 够 非常 智能 地 批量 处 理 来 自 上 游 的 事件 ， 从 而 实现 分 组 、 采 样 和 窗口 移动 的 功能 。 但 
是 ，buffer() 关闭 当前 缓冲 时 需要 创建 一 个 中 间 的 List， 然 后 才能 将 其 传递 到 下 游 ， 这 可 
能 会 给 垃圾 回收 和 内 存 使 用 带 来 不 必要 的 压力 (参见 8.6 节 )。 因 此 ，window() 操作 符 应 运 
而 生 。 


6.1.3 ”窗口 移动 


我 们 在 使 用 buffer() 时 需要 不 断 地 创建 List 实例 。 既 然 如 此 ， 为 什么 要 创建 这 些 中 间 的 
List， 而 不 是 以 某 种 方式 直接 在 运行 时 消费 事件 呢 ? 这 就 是 window() 操作 符 的 用 武之 地 
了 。 如 有 果 可 能 ， 我 们 应 该 优先 使 用 window()， 而 不 是 buffer() 操作 符 ， 因 为 后 者 在 内 存 消 
耗 方面 的 行为 更 难 预 料 。window() 操作 符 与 buffer() 非常 类 似 : 它 有 类 似 的 重 载 版 本 ， 包 
括 如 下 功能 的 重 载 形式 。 


。 接收 int 类型， 将 来 自 源 的 事件 分 组 到 固定 大 小 的 列表 中 。 

。 接收 时 间 单 元 ， 将 事件 按照 固定 的 时 间 阶 段 进 行 分 组 。 

。 接收 自 定 义 的 Observable， 用 来 标记 每 个 批 次 的 开始 和 结束 。 

那么 ， 差 异 何 在 呢 ?” 前 面 提 到 过 记录 指定 源 每 秒 产 生 事件 数量 的 样 例 ， 接 下 来 重新 看 一 下 
这 个 样 例 。 


Observable<KeyEvent> keyEvents = //... 

































































































































































Observable<Integer> eventPerSecond = keyEvents 
.buffer(1, SECONDS) 
.map(List::size); 


样 例 批量 获取 0bservable<KeyEvent> 每 秒 产生 的 事件 ， 并 将 其 放 到 0bservable<List<KeyEvent>> 
中 。 下 一 步 通 过 map 将 List 映射 为 它 的 size。 这 相当 浪费 ， 每 秒 产生 的 事件 数量 非常 大 
就 更 是 如 此 。 

Observable<Observable<KeyEvent>> windows = keyEvents.window(1, SECONDS); 


Observable<Integer> eventPerSecond = windows 
.flatMap(eventsInSecond -> eventsInSecond.count()); 


























与 buffer() 不 同 ，wtndow() 返回 的 是 一 个 0Observable<0bservable<KeyEvent>>。 这 里 接收 
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的 不 是 固定 的 列表 ， 这 类 列表 每 个 存放 一 个 批 次 (或 缓冲 )， 接 收 的 是 由 一 系列 流 组 成 的 
流 。 每 次 新 的 批 次 开始 的 时 候 (在 上 述 样 例 中 就 是 每 一 秒 )， 在 外 层 流 中 都 会 出 现 一 个 新 
的 Observable<KeyEvent> 值 。 这 些 内 部 流 可 以 进一步 转换 ， 但 是 为 了 人 避免 双重 包装 ， 我 们 
使 用 flatMap()。flatMap() 会 接收 每 个 缓冲 (0bservable<KeyEvent>) 作为 参数 ， 并 预期 
返回 另外 一 个 Observable。count() 操作 符 (参见 3.4 节 ) 会 将 0bservable<T> 转换 成 一 个 
Observable<Integer>， 它 只 发 布 一 个 条 目 ， 这 个 条 目 代 表 了 原始 Observable 中 的 事件 数 
量 。 因 此 ， 对 于 样 例 生成 的 所 有 一 秒 批 次 ， 就 是 该 秒 内 发 生 的 事件 数量 。 但 是 ， 这 里 没有 
内 部 的 缓冲 ，count() 操作 符 会 在 事件 通过 时 动态 地 记录 它们 的 数量 。 


6.1.4 ”借助 debounce() 跳 过 陈旧 的 事件 


buffer() 和 window() 会 将 儿 个 事件 组 合 在 一 起 ， 从 而 对 它们 进行 批量 处 理 。sample() 偶尔 
会 随机 选取 一 个 事件 。 这 些 操作 符 并 没有 考虑 事件 之 间 的 时 间 间 隔 。 但 是 在 很 多 场景 下 ， 
如 果 某 个 事件 紧 跟 着 另外 一 个 事件 ， 那 么 前 者 可 能 就 会 被 丢弃 。 例 如 ， 假 设 有 一 个 股票 价 
格 形成 的 流 从 交易 平台 流出 。 
Observable<BigDecimal> prices = tradingPLatform.pricesOf("NFLX'" ); 
Observable<BigDecimal> debounced = prices.debounce(100, MILLISECONDS); 


debounce() ( 即 throttlewithTimeout()) 将 会 丢弃 紧 随 另 一 个 事件 的 所 有 事件 。 换 句 话 
说 ， 如 果 给 定 事件 与 另 一 个 事件 的 间隔 超出 了 时 间 窗 口 ， 那 么 这 个 值 才 会 发 布 出 去 。 在 前 
再 的 样 例 中 ， 每 当 NFLX 股票 的 价格 发 生变 化 ，prices 流 就 会 推送 该 价格 。 有 了 时候 ， 股 票 
介 格 的 变动 会 非常 频繁 ， 每 秒 就 会 有 十 多 次 变化 。 对 于 价格 的 每 次 变动 ， 我 们 都 会 运行 一 
些 计算 ， 而 这 些 计 算 需 要 耗费 一 定 的 时 间 才 能 完成 。 但 是 ， 如 果 有 新 价格 出 现 ， 之 前 的 计 
算 就 没有 意义 了 ， 要 根据 新 价格 从 头 开 始 计算 。 因 此 ， 如 果 某 些 事件 紧 随 一 个 新 事件 (或 
者 说 被 新 事件 抑制 了 ) ， 我 们 可 能 想 要 将 其 丢弃 。 


debounce() 会 等 待 一 小 段 时 间 (在 前 面 的 样 例 中 也 就 是 100 毫秒 )， 以 防 第 二 个 事件 会 随 
后 出 现 。 这 个 过 程 会 不 断 重复 。 所 以 ， 如 果 第 二 个 事件 出 现时 ， 距 离 第 一 个 事件 不 超过 
100 毫秒 ，RxJava 将 会 延迟 它 的 发 布 ， 并 期 待 第 三 个 事件 的 出 现 。 这 里 依然 可 以 灵活 控制 
每 个 事件 的 等 待 时 间 。 例 如 ， 如 果 股 票 价格 的 更 新 间隔 小 于 100 毫秒 ， 我 们 可 能 想 忽 略 
它 。 但 是 ， 如 果 价 格 超过 了 150 美元 ， 我 们 可 能 就 想 立 刻 将 这 样 的 更 新 更 快 地 转发 至 下 
游 。 有 些 类 型 的 事件 可 能 需要 立即 处 理 ， 比 如 它们 代表 着 巨大 的 市 场 机 会 。 使 用 重 载 版 本 
的 debounce()， 可 以 很 容易 地 实现 这 种 需求 。 
prices 
.debounce(x -> { 
boolean goodPrice = x.compareTo(BigDecimal.valueOf(150)) > 0; 


return Observable 


.empty() 
.delay(goodPrice? 10 : 100, MILLISECONDS); 






























































































































































































































































}) 
对 于 价格 x 的 每 次 更 新 ， 样 例 都 会 应 用 一 个 复杂 的 逻辑 (大 于 150 美元 ) ， 以 判断 价格 是 
否 合适 。 然 后 ， 对 于 每 次 这 样 的 变更 ， 样 例 都 会 返回 唯一 的 0Observable。 这 个 0bservable 








是 空 的 ， 不 需要 发 布 任何 条 目 ， 重 要 的 是 它 何 时 能 够 完成 。 对 于 合适 的 价格 ， 这 个 








0bservable 会 在 10 毫秒 后 发 布 一 个 完成 通知 ， 而 对 于 其 他 的 价格 ， 它 会 在 100 毫秒 之 后 完 
成 。debounce() 对 接收 到 的 每 个 事件 都 订阅 该 0bservable， 并 等 待 它 的 完成 。 如 果 它 首先 完 
成 ， 这 个 事件 会 发 布 到 下 游 。 否 则 ， 如 果 更 新 的 上 游 事件 同时 出 现 ， 这 个 循环 将 会 重复 执行 。 


在 样 例 中 ， 价 格 x 的 值 为 140 美元 时 ，debounce() 会 创建 一 个 新 的 Observable， 根 据 传递 
的 表达 式 ， 这 个 0bservable 会 延迟 100 毫秒 完成 。 如 果 在 这 个 事件 完成 之 前 ， 没 有 其 他 
事件 出 现 ， 这 个 140 美元 的 事件 就 会 转发 到 下 游 。 但 是 ， 假 设 价 格 x 更 新 为 151 美元 。 这 
次 ，debounce() 要 求 提 供 Observable (在 API 中 ， 名 为 debounceSelector) 上 时， 返回 了 一 
个 完成 时 间 要 短 得 多 的 流 ，10 毫秒 就 可 以 完成 。 所 以 ， 如 果 出 现 了 合适 的 价格 (大 于 150 
美元 ) ， 只 需 等 10 毫秒 就 可 以 判断 是 否 出现 后 续 的 更 新 。 如 果 你 依然 很 难 理解 debounce() 
的 工作 原理 ， 可 以 尝试 运行 下 面 的 股票 价格 模拟 程序 。 
Observable<BigDecimal> pricesOf(String ticker) { 
return Observable 
.interval(50, MILLISECONDS) 
.flatMap(this: :randomDelay) 


.map(this: :randomStockPrice) 
.map(BigDecimal: :valueOf); 

























































































} 


Observable<Long> randomDelay(long x) { 
return Observable 
.just(x) 
.deLay((Long) (Math.random() * 100), MILLISECONDS); 
} 


double randomStockPrice(long x) { 
return 100 + Math.random() * 10 + 
(Math.sin(x / 100.0)) * 60.0; 
} 


上 述 样 例 很 漂亮 地 将 多 个 流 组 合 在 了 一 起 。 首 先 ， 生 成 一 个 Long 类 型 的 序列 ， 它 们 按照 
国定 的 50 毫秒 间隔 发 布 。 然 后 ， 每 个 事件 独立 地 延迟 0~100 毫秒 。 最 后 ， 将 无 限 递 增 的 
long 类 型 数字 转换 为 随机 抖动 的 正弦 曲线 (使 用 Math.sin())。 这 模拟 了 股票 价格 随时 间 
的 波动 。 如 果 使 用 debounce() 运行 这 个 流 ， 你 会 发 现 如 果 价 格 比较 低 ， 事 件 就 不 会 频繁 出 
现 ， 因 为 要 等 待 后 续 的 事件 100 毫秒 ， 而 后 续 事件 经 常 发 生 。 但 是 ， 如 果 价 格 超过 了 150 美 
元 ，debounce() 的 容量 就 降低 到 了 10 毫秒 ， 这 样 ， 每 个 合适 价格 的 更 新 都 会 转发 至 下 游 。 
避免 在 debounce() 中 出 现 饥饿 现象 
很 容易 想象 在 某 种 情景 下 ，debounce() 操作 符 会 阻止 所 有 事件 的 发 布 ， 因 为 这 些 事件 出 现 
得 过 于 频繁 ， 没 有 片刻 停歇 。 
Observable 

.interval(99, MILLISECONDS) 

.debounce(100, MILLISECONDS) 
这 样 的 源 不 会 发 布 任何 的 事件 ， 因 为 debounce() 会 等 待 100 毫秒 ， 以 确保 没有 新 的 事件 发 
生 。 令 人 遗憾 的 是 ， 在 距离 这 个 超时 还 有 1 毫秒 的 时 候 ， 新 事件 就 出 现 了 ， 这 样 会 重新 启动 
debounce 的 计时 器 。 这 导致 ， 如 果 一 个 0bservable 生成 事件 过 于 频繁 ， 我 们 可 能 永远 都 看 不 
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到 任何 的 事件 ! 你 可 以 将 其 称 为 一 种 特性 ， 但 是 在 实践 中 ， 即 便 出 现 了 事件 洪峰 ， 我 们 依然 
想 要 不 时 地 看 到 一 些 事件 。 为 了 避免 上 述 情况 的 出 现 ， 需 要 采取 一 些 有 创造 性 的 做 法 。 


首先 ， 样 例 必 须 识 别 是 否 存在 长 时 间 没 有 新 事件 出 现 的 情况 。7.1.3 节 会 介绍 timeout() 操 
作 符 ， 其 实 这 部 分 非常 简单 。 
Observable 
.interval(99, MILLISECONDS) 


.debounce(100, MILLISECONDS) 
.timeout(1, SECONDS); 


现在 ， 至 少 能 够 得 到 一 个 异常 信号 ， 提 示 上 游 源 是 空闲 的 。 令 人 惊讶 的 是 ， 事 实 恰好 相 
反 。 上 游 的 interval() 操作 符 生 成 事件 过 于 频繁 ， 所 以 debounce() 并 没有 将 它们 传递 
到 下 游 ， 我 们 在 这 里 有 点 误 入 歧途 了 。 如 果 事 件 出 现 得 过 于 频繁 ， 样 例会 将 它们 临时 保 
留 并 停 软 片刻 。 但 是 如 果 这 个 沉默 等 待 的 时 间 太 长 (超过 1 秒 )， 程 序 就 会 失败 并 抛 出 
TimeoutException。 与 其 让 程序 永远 失败 ， 我 们 更 希望 看 到 上 游 observable 中 的 任意 一 个 
值 并 继续 运行 。 任 务 的 第 一 部 分 非常 简单 。 
ConnectableObservable<Long> Upstream = Observable 
.interval(99, MILLISECONDS) 
.publish(); 
upstream 
.debounce(100, MILLISECONDS) 


.timeout(1, SECONDS, upstream.take(1)); 
upstream.connect(); 


timeout() 操作 符 有 一 个 重 载 版 本 ， 能 够 在 超时 的 情况 下 接收 一 个 备用 的 Observable。 但 
是 ， 这 里 有 一 个 小 缺陷 。 如 果 出 现 超时 ， 这 里 只 会 从 上 游 中 获取 第 一 个 条 目 就 结束 了 。 我 
们 真正 想 要 达到 的 效果 是 继续 发 布 upstrean 中 的 事件 ， 并 依然 支持 debounce()。 
























































ConnectableObservable 





在 这 里 需要 将 ConnectabLe0bservable 与 publish()、connect() 组 合 使 用 ， 
从 而 将 cold 类 型 的 Observable.interval() 转换 成 hot 类 型 (参见 2.4.4 节 ， 
了 解 interval() 为 何 是 cold 类 型 以 及 这 意味 着 什么 )。 通 过 调用 publish() 
和 connect() (参见 2.7.2 节 )， 强 迫 interval() 操作 符 立 即 生成 事件 ， 即 便 
无 人 订阅 。 这 意味 着 ， 如 果 几 秒 之 后 再 订阅 这 个 0bservable， 它 就 会 从 中 间 
开始 接收 事件 ， 所 有 的 订阅 者 会 在 同一 时 刻 得 到 相同 的 事件 。 默 认 情 况 下 ， 
interval() 是 cold 类 型 的 bbservable， 所 以 每 个 订阅 者 不 管 何 时 订阅 ， 都 会 
从 头 开始 接收 事件 。 








如 下 的 另外 一 种 方式 看 上 去 会 更 好 一 些 。 


Upstream 
.debounce(100, MILLISECONDS) 
.timeout(1, SECONDS, upstream 
.take(1) 
.ConcatWith( 
upstream.debounce(100, MILLISECONDS))) 





乍 看 上 去 ， 它 是 没有 问题 的 。 最 初 的 源 在 应 用 debounce() 操作 符 之 后 有 一 个 超时 操作 符 。 
出 现 超时 的 时 候 ， 样 例会 发 布 遇 到 的 第 一 个 条 目 ， 然 后 继续 使 用 相同 的 源 ， 这 也 是 通过 
debounce() 操作 符 实现 的 。 但 是 ， 如 果 出 现 第 一 次 超时 ， 我 们 切换 到 了 备用 0bservable 
上 ， 而 这 个 0bservable 是 没有 使 用 timeout() 操作 符 的 。 有 一 种 快速 、 混 乱 且 短视 的 修正 
方案 ， 如 下 所 示 。 
Upstream 
.debounce(100, MILLISECONDS) 
.timeout(1, SECONDS, upstream 
.take(1) 
.concatWith( 
upstream 
.debounce(100, MILLISECONDS) 
.timeout(1, SECONDS, upstream))) 


以 上 代码 再 次 忘记 了 在 内 层 timeout() 操作 符 中 添加 备用 observabLe。 足 够 了 ， 你 应 该 
已 经 注意 到 了 递归 模式 。 与 其 重复 使 用 相同 形式 的 upstream 一 debounce 一 timeout() 一 
upstream 一 …， 其 实 可 以 使 用 递归 。 


import static rx.0bservabtLe.defer; 



































Observable<Long> timedDebounce(Observable<Long> Upstream) { 
Observable<Long> onTimeout = Upstream 
.take(1) 
.concatWith(defer(() -> timedDebounce(upstream))); 
return upstream 
.debounce(100, MILLISECONDS) 
.timeout(1, SECONDS, onTimeout); 


} 


在 timedDebounce 中 ， 备 用 0bservable 的 onTimeout 比较 复杂 。 它 声明 首先 要 从 upstream 
(这 是 最 初 的 源 ) 中 获取 第 一 个 采样 事件 ， 随 后 递归 调用 timedDebounce() 方法 。 样 例 必须 
使 用 defer() 来 避免 无 穷 递归 。timedDebounce() 的 剩余 内 容 基 本 上 就 是 基于 最 初 的 上 游 
源 ， 应 用 debounce() 操作 符 并 添加 备用 onTimeout。 这 个 备用 0bservable 做 了 完全 相同 的 
事情 : 递归 地 应 用 debounce()、 添 加 timeout() 和 备用 Observable。 























如 果 你 觉得 上 述 代 码 难 以 理解 ， 不 必 感 到 诅 形 。 这 是 一 个 非常 复杂 的 样 例 ， 
展现 了 流 组 合 、 延 迟 执 行 和 递归 的 威力 。 我 们 很 少 需要 这 么 高 的 复杂 程度 ， 
但 是 掌握 了 它 的 运行 原理 之 后 ， 你 会 很 有 成 就 感 。 请 仔细 研读 这 段 代码 ， 并 
观察 微小 的 变化 会 如 何 极 大 地 影响 流 之 间 的 交互 方式 。 


6.2 回 压 


对 于 构建 健壮 和 即时 响应 的 应 用 程序 ， 回 压 (backpressure) 是 至 关 重 要 的 。 在 本 质 上 ， 它 
是 一 个 消费 者 到 生产 者 的 反馈 通道 。 消 费 者 能 够 在 一 定 程度 上 控制 它 随时 能 够 处 理 多 少数 
据 。 这 样 在 高 负载 的 情况 下 ， 消 费 者 或 消息 中 间 件 不 会 变 得 饱和 而 无 响应 。 相 反 ， 它 们 可 
以 请 求 更 少 的 信息 ， 由 生产 者 决定 如 何 放 慢 速度 。 
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在 所 有 通过 消息 传递 (或 事件 ) 进行 数据 交换 的 系统 中 ， 都 可 能 会 出 现 消费 者 的 节奏 跟 不 
上 生产 者 的 问题 。 根 据 底层 实现 的 不 同 ， 这 种 问题 可 能 会 表现 为 不 同 的 形式 。 如 果 通 信 通 
道 以 某 种 方式 同步 生产 者 和 消费 者 (比如 使 用 ArrayBtocktingqueue) ， 当 消费 者 跟 不 上 负载 
的 变化 时 ， 生 产 者 就 会 节 流 (阻塞 )。 这 将 会 导致 产 者 和 消费 者 之 问 产生 耦合， 而 两 者 
本 应 是 完全 独立 的 。 消 息 传递 一 般 意味 着 异步 处 理 ， 如 果 生 产 者 必须 要 等 待 消费 者 ， 那 么 
这 种 假设 就 难以 成 立 了 。 更 粳 粒 的 是 ， 在 更 高 层级 上 来 看 ， 这 个 生产 者 可 能 还 是 其 他 生产 
者 的 消费 者 ， 这 会 导致 延迟 的 级 联 增加 。 

相反 ， 即 使 两 者 的 沟通 介质 是 无 界 的 ， 它 依然 会 受到 无 法 控制 的 因素 的 制约 。 像 
LinkedBtockingQueue 这 样 的 无 限 队列 ， 允 许 生 产 者 在 不 阻塞 的 前 提 下 存放 大 量 超出 消费 者 
处 理 能 力 的 消息 。 换 名 话说， 在 LinkedBtockingQueue 没有 消耗 掉 所 有 的 内 存 并 让 应 用 程 
序 崩溃 之 前 ， 其 实 可 以 一 直 往 里 面 堆放 消息 。 如 果 中 间 介质 是 持久 化 的 ， 比 如 JMS 的 消息 
代理 《message broker) ， 同 样 的 问题 会 以 磁盘 空间 的 形式 表现 出 来 ， 但 是 这 种 情况 发 生 的 
可 能 性 比较 低 。 更 加 常见 的 情况 是 ， 消 息 中 间 件 难以 管理 数 千 条 其 至 数 百 万 条 未 使 用 的 消 
息 。 有 些 特殊 的 代理 (broker)， 比 如 Kafka， 在 技术 上 能 够 存储 数 亿 条 消息 ， 直 到 处 理 速 
度 落后 的 消费 者 获取 到 这 些 消息 为 止 。 但 是 ， 这 会 导致 延迟 的 大 幅 增 加 ， 这 里 的 延迟 指 的 
是 消息 的 生产 和 消费 的 间隔 时 间 。 


尽管 通常 认为 消息 驱动 的 系统 更 加 健壮 和 可 扩展 ， 但 是 生产 者 过 于 活跃 的 问题 依然 存在 。 
不 过 ， 为 了 解决 这 个 集成 相关 的 问题 ,已 经 有 了 一 些 相 关 的 尝试 。 在 RxJava 中 ， 采 样 、 
节 流 (使 用 sample() 等 ) 以 及 批 处 理 (使 用 window() 和 buffer()) 是 手动 减少 生产 者 负 
载 的 方法 。0bservablte 生成 的 事件 数量 超过 消费 能 力 时 ， 可 以 使 用 采样 或 批 处 理 增加 订阅 
的 吞吐 量 。 然 而 ， 我 们 需要 更 加 健壮 和 系统 化 的 方案 ， 所 以 反应 式 流 (Reactive Stream ) 
应 运 而 生 。 这 是 一 组 很 小 的 接口 和 语义 集 ， 旨 在 正式 解决 这 个 问题 ， 并 为 生产 者 和 消费 者 
的 协调 提供 一 个 系统 化 的 算法 ， 即 回 压 。 

回 压 是 一 个 简单 的 协议 ， 它 允许 消费 者 请 求 一 次 可 以 消费 多 少数 据 ， 实 际 上 是 提供 了 一 条 
外 向 生产 者 的 反馈 通道 。 生 产 者 接收 来 自 消费 者 的 请 求 ， 人 避免 消 息 滚 出。 当然， 这 种 算法 
只 能 用 于 生产 者 能 够 对 自己 进行 节 流 的 场景 ， 比 如 它们 使 用 静态 集合 作为 支撑 ,或 者 数据 
源 通过 类 似 Iterator 这 样 的 形式 进行 拉 取 。 如 果 生 产 者 无 法 控制 生成 数据 的 频率 (数据 源 
是 外 部 的 ， 或 者 是 hot 类 型 的 ) ， 那 么 回 压 也 提供 不 了 太 大 的 帮助 。 


6.2.1 RxJava 中 的 回 压 


尽管 反应 式 流 以 技术 中 立 的 方式 解决 了 一 个 普遍 存在 的 问题 ， 但 是 我 们 依然 要 关注 
RxJava， 关 注 它 是 如 何 解决 回 压 问题 的 。 本 章 将 会 使 用 小 餐馆 中 刷 盘 子 的 样 例 ， 这 里 将 盘 
子 建 模 为 具有 一 个 标识 符 的 大 对 象 。 

class Dish { 


private final byte[] oneKb = new byte[1_ 024] ; 
private final int id; 































































































































































































Dish(int id) { 
this.id = id; 
System.out.println("Created: " + id); 





public String toString() { 
return String.valueOf(id); 
} 
} 


这 里 的 onekb 缓冲 区 只 是 为 了 模拟 一 些 额外 的 内 存 占 用 。 盘 子 通过 服务 员 传递 给 厨房 ， 我 
们 将 其 建 模 为 bservabte。 


Observable<Dish> dishes = Observable 
.range(1, 1_000_000_000) 
.map(Dish: :new); 


range() 操作 符 会 尽 可 能 快 地 生成 新 的 值 。 如 有 果 刷 盘子 需要 一 些 时 间 ， 而 且 明 显要 比 生成 
的 节奏 慢 ， 将 会 发 生 什么 呢 ? 


Observable 

.range(1, 1_000_000_000) 

.map(Dish: :new) 

.Subscribe(x -> { 
System.out.println("Washing: " + x); 
sleepMillis(50); 

]); 


有 点 令 人 意外 ， 情 况 并 不 糟糕 。 如 果 你 研读 一 下 输出 ， 就 会 发 现 range() 与 订阅 完全 匹配 。 


Created : 
Washing : 
Created : 
Washing : 
Created : 
Washing : 














LO UN 记 六 请 


Created: 110 
Washing: 110 


这 应 该 并 不 意外 。range() 操作 符 默 认 并 不 是 异步 的 ， 所 以 它 生 成 的 每 个 条 目 会 直接 在 当 
前 线程 的 上 下 文中 传递 给 Subscriber。 如 果 Subscriber 比较 缓慢 ， 就 阻止 了 0bservable 
生成 更 多 的 元 素 。 在 前 一 个 条 目 完成 之 前 ，range() 无 法 调用 Subscriber 的 onNext()。 这 
可 能 是 因为 生产 者 和 消费 者 在 同一 个 线程 中 运行 ， 二 者 透明 地 耦合 在 一 起 。 在 某 种 程度 上 
可 以 说 ， 它 们 之 间 有 一 个 隐 式 的 队列 ， 这 个 队列 的 最 大 容量 就 是 1。 这 是 我 们 始 料 未 及 的 
会 合 (rendezvous) 算法 。 假 设 饭店 的 服务 员 在 当前 的 盘子 洗 完 之 前 ， 无 法 将 新 的 竺 洗盘 
子 送 到 厨房 ， 而 且 服 务 员 必 须要 站 在 那里 等 待 盘子 洗 完 ， 此 时 顾客 就 没 人 招待 了 。 这 些 顾 
客 没 有 得 到 招待 ， 新 顾客 也 没有 办 法 进入 餐厅 。 这 样 ， 阻 塞 式 组 件 让 整个 系统 陷入 了 停 
顿 。 但 是 ， 在 实际 中 ， 生 产 者 和 消费 者 之 间 会 有 一 个 线程 边界 : 0bservable 在 一 个 线程 中 
生产 事件 ， 而 Subscriber 在 另 一 个 线程 中 消费 事件 。 
dishes 
.observeOn(Schedulers.io()) 


.Subscribe(x -> { 
System.out.println("Washing: " + x); 
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sleepMillis(50); 
}); 





先 暂 停 一 下 ， 想 想 如 果 不 实际 编译 和 运行 代码 会 发 生 什 么 。 有 人 可 能 认为 会 产生 灾难 性 的 
结果 ， 因 为 来 自 range() 操作 符 的 dishes 会 非常 快 地 生成 事件 ， 而 Subscriber 消费 的 速 























度 非 常 慢 ， 每 秒 只 能 消费 20 个 盘子 。observe0n() 操 人 








FE 符 能 够 持续 快速 地 消费 事件 ， 但 是 


Subscriber 消费 事件 的 方式 太 慢 了 。 所 以 你 可 能 会 得 出 结论 : 0utofMemoryError 是 难以 避 





免 的 ， 依 据 就 是 未 处 理 的 事件 会 在 某 处 堆积 。 幸 而 ， 
定 程度 上 保护 了 我 们 。 程 序 的 输出 有 点 出 人 意料 。 
Created: 1 


Created: 2 
Created: 3 





Created: 128 


Washing: 1 
Washing: 2 


Washing: 128 
Created: 129 


Created: 223 
Created: 224 


Washing: 129 
Washing: 130 


首先 ，range() 几乎 在 瞬间 生成 了 一 批 盘 子 (128 个 )。 





回 压 扭转 了 败局 ， 而 且 RxJava 在 一 


随后 ， 是 比较 慢 的 逐个 刷 盘 子 的 过 


程 。 在 某 种 程度 上 来 说 ， 此 时 range() 操作 符 空间 了 下 来 。 这 128 个 盘子 中 的 最 后 一 个 清 
洗 完毕 之 后 ，range() 又 生成 了 一 批 盘子 (96 个 )， 在 之 后 又 是 缓慢 的 清洗 过 程 。’ 显然 ， 
这 里 必须 存在 某 种 智能 的 机 制 避免 range() 生成 太 多 的 事件 ， 具 体 生 成 事件 的 数量 由 订阅 
者 控制 。 如 果 你 没有 看 到 这 种 机 制 是 在 哪里 发 挥 作用 的 ， 那 尝试 一 下 自行 实现 range()。 


Observable<Integer> myRange(int from, int count) { 


return Observable.create(subscriber -> { 
int i = from; 
while (i < from + count) { 
if (!subscriber.isUnsubscribed()) { 
subscriber .onNext(iL++) ; 
} else { 
return; 


subscriber .onCompleted(); 
}); 
} 














接 下 来 ， 在 相同 的 样 例 中 结合 observe0n() 来 使 用 myRange()。 























注 2: 不 必 过 分 关注 盘子 具体 的 数量 ， 关 键 的 是 请 求 批量 事件 的 周期 性 。 
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myRange(1，1_ 000 000 000) 
.map(Dish: :new) 
.observeOn(Schedulers.io()) 
.Subscribe(x -> { 
System.out.println("Washing: " + x); 














sleepMillis(50); 
}， 
Throwable: :printStackTrace 
); 
最 终 的 结果 是 灾难 性 的 ， 一 个 盘子 都 没有 清洗 。 
Created: 1 
Created: 2 
Created: 3 


Created: 7177 
Created: 7178 


rx.exceptions.MissingBackpressureException 
at rx.internal.operators... 
at rx.internal.operators... 





随后 将 会 阐述 MissingBackpressureException。 现 在 ， 你 能 够 确信 自 定 义 的 range() 实现 缺 
少 了 某 种 后 台 机 制 。 


6.2.2 内置 的 回 压 


我 们 在 前 儿童 观察 了 事件 是 如 何 从 源 0bservable 流 到 下 游 的 ， 这 个 过 程 会 经 历 一 系列 的 操 
作 符 ， 然 后 到 达 一 个 Subscriber。 订 阅 请 求 并 没有 任何 的 反馈 通道 。 样 例 调用 subscribe() 
的 时 候 (在 某 种 意义 上 是 向 上 传递 )， 所 有 的 事件 和 通知 都 会 向 下 传递 ， 中 间 没 有 任何 明 
显 的 反馈 回路 。 缺 少 反 馈 可 能 会 导致 生产 者 〈 最 高 的 Observable) 发 布 大 量 的 事件 ， 这 超 
出 了 订阅 者 的 处 理 能 力 。 结 果 就 是 ， 应 用 程序 可 能 会 因为 OutofMemoryError 而 崩溃 ， 或 者 
再 好 一 点 ， 但 也 存在 很 大 的 六 在 威胁 。 


回 压 机 制 能 够 让 终端 订阅 者 和 中 间 操 作 符 从 生产 者 那里 只 请 求 特定 数量 的 事件 。 默 认 情 况 
下 ， 上 游 cold 类 型 的 0bservable 会 尽快 生成 事件 。 但 是 ， 下 游 发 起 这 类 请 求 时 ， 它 应 该 
按照 某 种 方式 “ 慢 下 来 ”并 生成 符合 请 求 数 量 的 事件 。 这 样 ， 在 observeon() 中 就 出 现 了 
128 这 个 神奇 的 数字 。 但 是 ， 先 看 一 下 最 终 的 订阅 者 是 如 何 控制 回 压 的 。 
订阅 时 ， 样 例 可 以 实现 onNext()、onCompleted() 和 onError() (参见 2.2 节 )。 实 际 上 还 有 
另外 一 个 回调 方法 : onStart()。 

Observable 


.range(1, 10) 
.Subscribe(new Subscriber<Integer>() { 



















































































@Override 

public void onStart() { 
request(3); 

} 
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// 随 后 是 onNext，onCompLeted，onError.…… 
]); 
RxJava 调用 onstart() 的 时 机 和 我 们 预想 的 一 样 ， 也 就 是 在 事件 或 通知 传递 到 Subscriber 
之 前 。 在 技术 上 ， 你 可 以 使 用 Subscriber 的 构造 器 ， 但 是 对 于 Java 中 的 匿名 内 部 类 ， 构 
造 器 看 上 去 有 些 怪异 。 


.Subscribe(new Subscriber<Integer>() { 














{{ 
}} 


request(3); 


// 随 后 是 onNext，onCompleted，onError*……: 
]); 


有 点 跑题 了 。 在 Subscriber 中 调用 request(3)， 会 向 上 游 的 源 指 明 我 们 最 开始 想 要 接收 的 
条 目 数 量 。 如 果 完 全 忽略 对 它 的 调用 (或 者 调用 request(Long.MAX_VALUE) ) ， 那 么 就 等 价 
于 请 求 尽 可 能 多 的 事件 。 这 就 是 尽早 调用 request() 原因 ， 如 果 流 已 经 开始 发 布 事件 ， 就 无 
法 减少 要 求 的 数量 了 。 但 是 ， 如 果 只 请 求 三 个 事件 ，range() 操作 符 会 在 推送 完 1、2 和 3 之 
后 暂时 停止 发 布 事件 。onNext() 回调 方法 会 被 调用 三 次 ， 之 后 ， 尽 管 range() 操作 符 还 没 
有 完成 ，onNext() 也 不 会 再 调用 了 。 但 是 ，Subscriber 完全 可 以 控制 想 要 接收 多 少数 据 。 
例如 ， 我 们 想 要 分 别 请 求 事件 。 
Observable 


.range(1, 10) 
.Subscribe(new Subscriber<Integer>() { 












































@Override 
public void onStart() { 
request(1); 


} 


@Override 

public void onNext(Integer integer) { 
request(1); 
log.info("Next {}", integer); 


//onCompleted, onError... 


}); 


这 个 样 例 有 点 牵强 ， 它 的 行为 与 没有 任何 回 压 功 能 的 普通 Subscriber 完全 一 样 。 但 是 ， 它 
阐明 了 如 何 使 用 回 压 。 你 可 以 想象 一 个 Subscriber， 它 可 以 预先 缓冲 一 定数 量 的 事件 ， 然 
后 在 方便 的 时 候 再 进行 批量 请 求 。 尽 管 Subscriber 处 于 空 闪 状态 ,但 它 依然 可 能 会 在 接收 
更 多 事件 之 前 等 待 一 会 儿 ， 比 如 为 了 减轻 对 下 游 依赖 的 压力 。 在 餐厅 样 例 中 ， 服 务 员 是 一 
个 不 断 推 送 新 的 脏 盘 子 的 0bservabLe<Dish>， 而 request(N) 表明 厨房 工作 人 员 准 备 清 洗 一 
定数 量 的 盘子 。 如 果 没 有 厨房 工作 人 员 的 请 求 ， 一 个 称职 的 服务 员 是 不 应 该 将 新 的 脏 盘 子 
传送 进来 的 。 























下 









































也 就 是 说 ， 在 客户 端 代码 中 直接 调用 request(N) 是 比较 少见 的 。 更 常见 的 情况 是 ， 放 
置 在 源 和 最 终 的 Subscriber 之 间 的 各 种 操作 符 ， 利 用 回 压 功 能 控制 有 多 少数 据 流 经 管 
道 。 例 如 ，observe0n() 必须 要 订阅 上 游 的 Observable， 并 在 一 个 特定 的 Scheduler ( 比 
如 io()) 中 调度 接收 到 的 事件 。 但 是 ， 如 果 上 游 生成 事件 的 速度 超过 了 底层 Scheduler 和 
Subscriber 的 处 理 速 度 ， 那 又 会 怎样 呢 ? observe0n() 创建 的 Subscriber 是 支持 回 压 的 ， 
它 最 初 只 会 请 求 128 个 值 。 上游 的 Observable 能 够 理解 回 压 机 制 ， 所 以 只 发 布 给 定数 量 
的 事件 ， 然 后 就 会 处 于 空闲 状态 了 ， 这 就 是 样 例 中 range() 做 的 事情 。 当 observeon() 发 
现 当 前 批 次 的 事件 已 经 被 下 游 Subscriber 处 理 完毕 ， 它 会 请 求 更 多 的 事件 。 这 样 尽管 跨越 
了 线程 边界 ， 而 且 生 产 者 和 消费 者 端 都 是 异步 的 ， 消 费 者 依然 不 会 被 事件 洪峰 击 涡 。 


observe0n() 并 不 是 唯一 对 回 压 友 好 的 操作 符 ， 很 多 操作 符 也 充分 利用 了 回 压 功能 。 比 如 ， 
zip() 只 会 缓冲 来 自 底层 bbservable 的 固定 数量 的 事件 。 幸 亏 有 了 这 个 特性 ， 当 压缩 的 流 
只 有 一 个 非常 活跃 的 时 候 ，zip() 也 不 会 受到 影响 。 相 同 的 逻辑 适用 于 之 前 用 过 的 大 多 
数 操作 符 。 


6.2.3 Producer 与 缺失 回 压 场 景 


自 定义 的 range() 实现 中 ， 我 们 已 经 见 到 过 MissingBackpressureException 了 。 它 到 底 
意味 着 什么 ， 又 该 怎样 解读 这 个 异常 呢 ? 假设 有 个 Subscriber (可 能 是 自己 创建 的 ， 但 更 
稼 见 的 是 由 某 个 操作 符 创 建 的 )， 能 够 精确 知道 它 想 要 接收 多 少 个 条 目 ， 如 buffer(N) 或 
take(N)。 这 类 操作 符 的 另外 一 个 例子 是 observe0n()。 它 在 某 些 方面 必须 非常 严格 ， 如 
上 游 Observable 基于 某 种 原因 推送 了 更 多 的 和 条目， 那么 observe0n() 内 部 的 缓冲 将 会 洪 
出 ， 并 发 出 MissingBackpressureException 这 样 的 信号 。 话 又 说 回来 ， 上 游 0bservable 推 
送 的 条 目 为 什么 会 超出 请 求 的 数量 呢 ?” 这 只 是 因为 它 忽 略 了 对 request() 的 调用 。 我 们 
顾 一 下 简单 range() 的 重新 实现 ， 如 下 所 示 。 
Observable<Integer> myRange(int from, int count) { 
return Observable.create(subscriber -> { 
int i = from; 
while (i < from + count) { 
if (!subscriber.isUnsubscribed()) { 
subscriber .onNext(i+t+); 


} else { 
return; 
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酒 











回 





} 
} 


subscriber .onCompleted(); 


]); 
} 
停止 的 唯一 办 法 是 取消 订阅 ， 但 是 我 们 并 不 想 取消 订阅 ， 只 是 想 要 让 它 的 速度 减 慢 一 些 。 
下 游 的 操作 符 精确 地 知道 它们 想 要 接收 多 少 事 件 ， 但 是 源 忽略 了 这 些 请 求 。 用 于 表示 请 求 
的 事件 数量 的 底层 机 制 是 通过 rx.Producer 实现 的 。 这 个 接口 会 在 create() 的 时 候 插 进 
来 。 回 忆 一 下 ， 每 次 有 人 订阅 0bservable，OnSubscribeRange 回调 都 会 执行 。 通 常情 况 下 ， 




















注 3: 你 可 以 通过 rx.ring-buffer.size 系统 特性 改变 这 个 值 。 
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你 会 看 到 在 这 个 接口 中 直接 


Observable<Integer> my 
return Observable. 


class OnSubscribeRange 


// 构 造 器 …… 


@Override 
public void call(f 
child.setProdu 


} 

} 

class RangeProducer im 
@Override 
public void reques 


调用 onNext()， 但 是 考虑 到 回 压 的 时 候 就 不 会 这 样 做 了 。 


RangeWithBackpressure(int from, int count) { 
create(new OnSubscribeRange(from, count)); 














implements Observable.OnSubscribe<Integer> { 


inal Subscriber<? super Integer> child) { 
cer(new RangeProducer(child, start, end)); 


plements Producer { 


t(Long n) { 


// 在 这 里 调用 子 订阅 者 的 onNext() 





} 
} 


你 会 发 现 ， 这 就 是 RxJava 


的 range() 实现 中 的 骨架 人 代码。 实现 Producer 是 一 项 非常 有 


挑战 的 任务 ， 它 必须 是 有 状态 的 、 线 程 安全 的 ， 而 且 极 快 。 因 此 ， 一 般 不 会 自行 实现 
Producer ,但 是 理解 它们 的 运行 方式 是 很 有 帮助 的 (参见 6.2.4 市 ， 了 解 自行 实现 回 压 的 细 
节 )。 在 内 部 ， 回 压 是 将 Rx 的 理念 颠倒 过 来 。range() (以 及 其 他 大 量 内 置 的 操作 符 ) 生 





成 的 Observable 并 不 会 将 寻 
Subscriber 中 的 request(N) 
时 ， 它 能 够 确保 生成 的 事件 




















和 件 立 即 推送 给 Subscriber。 相 反 ， 只 有 在 进行 数据 请 求 (在 
调用 ) 的 时 候 ， 它 才 会 苏醒 过 来 并 做 出 反应 ， 生 成 事件 。 同 
不 会 超过 请 求 数量 。 


接 下 来 看 一 下 样 例 是 如 何在 chiLd Subscriber 上 设置 Producer 的 。Subscriber 调用 
request() 的 时 候 ， 这 个 Producer 就 会 在 Subscriber 中 被 间接 调用 。 这 样 就 建立 了 一 个 从 
Subscriber 到 源 0bservable 的 反馈 通道 。0bservable 指导 它 的 Subscriber 如 何 请 求 特 定 





数量 的 数据 。 实 际 上 ，obse 


选择 地 只 请 求 数量 有 限 的 事件 。 如 果 一 些 外 来 的 Observable 没有 建立 这 样 的 通道 会 怎么 样 
呢 ? RxJava 发 现 这 种 情况 时 ， 会 将 其 作为 不 支持 回 压 的 源 来 进行 处 理 ， 随 时 都 可 能 因为 
MissingBackpressureException 而 失败 。 但 是 ，onBackpressure*() 家 族 中 有 很 多 操作 符 都 


能 在 一 定 程度 上 模拟 回 压 。 


最 简单 的 onBackpressureBuffer() 操作 符 会 无 条 件 缓 冲 所 有 的 上 游 事 





数据 传递 给 下 游 订阅 者 。 








rvable 从 推送 模式 变 成 了 拉 取 - 推送 模式 ， 这 样 客户 端 可 以 有 









































首 将 请 求 数量 的 





了 
个 
I 
J 





myRange(1, 1_000_000_000) 
.map(Dish: :new) 


.OnBackpressur 
.observeOn(Sch 
.Subscribe(x - 


System.out.println("Washing: 


sl 


eBuffer() 
edulers.io()) 
> { 


+ xX); 
eepMillis(50); 





和 往常 一 样 ， 我 们 依然 从 下 往 上 阅读 。 首 先 ，subscribe() 向 上 传递 到 observeon() 操 
作 符 。observe0n() 也 必须 要 进行 订阅 ， 但 是 它 不 会 简单 地 消费 任意 数量 的 事件 。 开 
始 的 时 候 ， 它 只 会 请 求 固 定数 量 的 事件 (128 个 )， 避 免 io() Scheduler 的 队列 出 现 溢 
出 。onBackpressureBuffer() 操作 符 可 以 视 为 一 个 屏障 ， 防 止 源 忽 略 回 压 。 接 收 到 下 游 
Subscriber 的 request(128) 调用 时 ， 它 会 将 这 个 请 求 往 上 传递 ， 如 果 只 有 128 个 事件 流 
过 ， 它 什么 事情 都 不 会 做 。 但 是 ， 如 果 0bservable 忽略 了 这 个 请 求 ， 一 味 地 将 数据 往 下 游 
推送 ，onBackpressureBuffer() 在 内 部 会 保持 一 个 无 边界 的 缓冲 。 下 游 Subscriber 发 起 另 
外 一 个 请 求 时 ，onBackpressureBuffer() 首先 会 消耗 其 内 部 缓冲 的 数据 ， 只 有 缓冲 几乎 消 
耗 列 尽 的 时 候 ， 它 才 会 向 上 游 发 起 请 求 。 这 种 聪明 的 机 制 能 够 让 observe0n() 运行 得 就 像 
myRange() 支持 回 压 一 样 ， 但 实际 上 节 流 是 由 onBackpressureBuffer() 实现 的 。 令 人 遗憾 
的 是 ， 对 无 限 的 内 部 缓冲 并 不 能 掉以轻心 。 
Created: 
Created: 
Created: 
Created: 
Created: 
Created: 
Washing: 
Created: 
Created: 






























































此 上 Do 上 PP 请 


Created: 26976 
Created: 26977 
Washing: 15 
Exception in thread "main" java.Lang.O0utOfMemoryError: ... 
Washing: 16 
at java.util.concurrent.ConcurrentLinkedQueue.offer... 
at rx.internal.operators.OperatorOnBackpressureBuffer... 








当然 ， 你 的 情况 可 能 有 所 不 同 。 如 果 事 件 的 数量 更 少 并 且 有 足够 的 内 存 ， 那 么 在 技术 上 
onBackpressureBuffer() 是 可 以 运行 的 。 但 我 们 永远 都 不 应 该 依赖 没有 限制 的 资源 。 固 态 
硬盘 的 容量 是 有 限 的 ， 不 过 好 在 还 有 一 个 重 载 版 本 的 onBackpressureBuffer(N)， 它 能 够 指 
定 最 大 的 缓冲 空间 。 

.onBackpressureBuffer(1000，() -> Log.warn("Buffer fuLL" )) 


第 二 个 参数 是 可 选 的 ， 它 是 一 个 回调 。 当 有 界 的 1000 个 元 素 的 缓冲 被 填 满 时 ， 它 会 被 调 
用 ， 尽 管 subscriber 的 处 理 速度 依然 很 慢 。 它 不 会 尝试 进行 任何 的 恢复 操作 ， 所 以 在 警告 
信息 之 后 会 立即 出 现 MissingBackpressureException。 通 过 这 种 方式 ， 至 少 对 缓冲 有 了 自 
己 的 控制 ， 不 再 受 硬件 或 操作 系统 的 控制 。 


onBackpressureBuffer() 的 一 个 禁 代 方案 是 onBackpressureDrop()， 后 者 会 将 没有 预先 请 求 
(request()) 的 事件 直接 丢弃 。 假 设 在 餐厅 中 ， 服 务 员 将 新 的 待 清洗 的 盘子 不 断送 到 厨房 。 
onBackpressureBuffer() 就 像 一 张 能 够 有 限 或 无 限 堆放 的 桌子 ， 待 清洗 的 盘子 都 会 放 到 这 
里 。onBackpressureDrop() 则 与 之 不 同 ， 如 果 此 时 没有 清洗 能 力 ， 服 务 员 会 直接 把 脏 盘 子 
扔 掉 。 这 不 是 可 持续 的 商业 模式 ， 但 是 至 少 餐 厅 能 够 一 直 为 顾客 服务 。 


.OnBackpressureDrop(dish -> Log.warn("Throw away {}", dish)) 
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回调 是 可 选 的 ， 它 会 在 每 次 有 事件 丢弃 的 时 候 进 行 通知 ， 丢 弃 是 因为 没有 请 求 它 就 出 
现 了 。 跟 踪 丢 弃 事 件 的 数量 是 一 种 很 好 的 做 法 ， 这 是 一 项 重要 的 指标 。 最 后 ， 还 有 
onBackpressureLatest() 方法 ， 它 与 onBackpressureDrop() 非常 类 似 ， 但 是 它 会 引用 最 后 
一 个 被 丢弃 的 元 素 ， 这 样 ， 如 果 稍 后 调用 下 游 的 request()， 就 能 使 用 上 游 的 最 后 一 个 值 。 
onBackpressure*() 方法 族 提供 了 一 个 桥梁 ， 将 要 求 回 压 功能 的 操作 符 和 订阅 者 与 不 支持 
压 的 Observable 连接 在 一 起 。 但 是 ， 最 好 还 是 使 用 和 创建 原生 支持 回 压 的 源 。 


6.2.4 ”按照 请 求 返 回 指定 数量 的 数据 

构造 支持 下 游 回 压 请 求 的 0Observable， 方式 有 很 多 。 最 简单 的 方案 是 使 用 内 置 的 工厂 方 
法 ， 如 range() 或 from(Iterable<T>)。 后 者 会 创建 一 个 由 Iterable 作为 支撑 的 源 ， 但 是 
内 置 了 回 压 的 功能 。 这 意味 着 该 0bservable 并 不 会 将 Iterable 中 的 所 有 值 一 次 性 都 发 布 
出 去 ， 相 反 ， 它 会 在 消费 者 请 求 的 时 候 将 值 逐 渐 发 布 。 注 意 ， 这 并 不 意味 着 会 预先 将 所 有 
的 数据 都 加 载 到 List<T> (扩展 了 IterabLe<T>) 中 。 一 般 来 讲 ，Iterable 是 Iterator 的 一 
个 工厂 ， 所 以 我 们 可 以 在 运行 时 安全 地 加 载 数据 。 

在 实现 支持 回 压 的 observable 方面 ， 有 一 个 很 有 趣 的 例子 ， 那 就 是 将 来 自 JDBC 的 
ResultSet 包装 到 一 个 流 。 注 意 ，ResultSet 是 基于 拉 取 模型 的 ， 这 与 支持 回 压 的 0bservable 
非常 类 似 。 但 它 并 不 是 Iterable 或 Iterator， 所 以 必须 先 转换 成 Iterator<0bject[]>， 
0bject[] 是 数据 库 中 单个 行 的 松散 类 型 化 表述 。 


public class ResultSetIterator implements Iterator<0Object[]> { 























回 






































private final ResultSet rs; 


public ResultSetIterator(ResultSet rs) { 
this.rs = rs; 


3} 


@Override 
public boolean hasNext() { 
return !rs.isLast(); 


} 


@Override 
public Object[] next() { 
rs.next(); 
return toArray(rs); 
} 
} 


上 述 的 转换 器 是 一 个 非常 简单 的 版 本 ,没有 错误 处 理 ， 它 从 Apache Commons DbUtils 开源 
工具 库 中 的 ResultSetIterator 抽取 而 来 。 这 个 类 还 提供 了 对 Iterable<0bject[]> 的 简单 
转换 。 


public static Iterable<Object[]> iterable(final ResultSet rs) { 
return new Iterable<Object[]>() { 



































@Override 





public Iterator<0bject[]> iterator() { 
return new ResultSetIterator(rs); 


} 


ResultSet 的 处 理 

需要 记 住 ,将 ResultSet 视 为 Iterator (尤其 是 Iterable) 是 一 个 有 漏洞 的 
抽象 。 首 先 ，ResultSet 像 Iterator 一 样 具 有 破坏 性 ， 但 是 与 Iterable 不 同 。 
你 只 能 遍历 Iterator 一 次 ，ResuLtSset 通常 也 是 如 此 。 其 次 ，Iterable 是 全 
新 Iterator 的 工厂 ， 而 前 面 的 转换 器 始终 会 返回 由 同一 个 Resuttset 支撑 的 
Iterator。 这 意味 着 ， 调 用 iterator() 两 次 不 会 生成 相同 的 值 ， 两 个 迭代 器 
会 在 同一 个 ResutLtset 上 竞争 。 最 后 ，Resuttset 在 完成 的 时 候 必 须要 关闭 ， 
但 是 Iterator 没有 这 样 的 生命 周期 。 完 全 依赖 客户 端 代码 读 取 Iterator 来 进 

















行 清 理 就 显得 过 于 乐观 了 。 





这 些 转换 器 就 绪 之 后 ， 就 可 以 基于 Resultset 构建 支持 回 压 功能 


Connection connection = //... 
PreparedStatement statement = 
Connection.prepareStatement(" SELECT ..."); 
statement .setFetchSize(1000) ; 
ResultSet rs = statement.executeQuery(); 
Observable<0bject[]> result = 
Observable 
.from(ResultSetIterator.iterable(rs)) 
.doAfterTerminate(() -> { 
try { 
rs.close(); 
statement.close(); 
connection.close(); 
} catch (SQLException e) { 
log.warn("Unable to close", e); 





} 
}); 





的 Observable<0bject[]> 了 。 











这 里 得 到 的 result 0bservable 就 支持 回 压 了 ， 因 为 内 置 的 from() 操作 符 支 持 回 压 。 这 样 ， 











Subscriber 的 吞吐 量 就 无 关 紧 要 了 ， 也 不 会 再 看 到 MissingBac 











kpressureException。 注 意 ， 


setFetchsize() 是 非常 必要 的 ， 因 为 有 些 JDBC 驱动 可 能 会 尝试 将 所 有 记录 都 加 载 到 内 存 ， 























如 果 想 要 对 很 大 的 结果 集 进行 流 处 理 ， 这 是 非常 低 效 的 。 


正如 前 面 介绍 的 ， 支 持 回 压 的 底层 机 制 是 自 定 义 实 现 的 Produc 
出 错 ， 因 此 RxJava 创建 了 一 个 辅助 类 ， 即 SyncOnSubscribe。 
这 个 实现 是 基于 拉 取 模式 的 ， 并 且 透 明 地 将 回 压 加 入 进来 。 从 

















er。 但 是 这 项 任务 非常 容易 
0bservabLe.0nSubscribe 的 
最 简单 的 无 状态 0bservable 


开始 介绍 一 一 在 现实 生活 中 非常 少见 。 这 种 类 型 的 Observable 在 每 次 onNext() 调用 之 间 
不 会 持 有 任何 状态 。 但 是 ， 即 便 是 最 简单 的 range() 或 just() 也 必须 要 记得 发 布 过 哪些 条 
目 。 无 状态 0bservable 为 数 不 多 的 有 用 场景 之 一 就 是 发 布 随机 数 。 
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import rx.observables.SyncOnSubscribe; 


Observable.OnSubscribe<Double> onSubscribe = 
SyncOnSubscribe.createStateLess( 
observer -> observer .onNext(Math.random()) 


); 
Observable<Double> rand = Observable.create(onSubscribe); 


rand 0bservable 是 一 个 普通 的 0bservable， 它 可 以 进行 转换 、 组 合 和 订阅 。 但 是 ， 在 内 
部 ， 它 对 回 压 提供 了 完整 的 支持 。 如 果 Subscriber 或 管道 上 的 其 他 操作 符 请 求 有 限 数量 
的 事件 ， 这 个 0bservable 就 会 完全 遵守 这 个 要 求 。 只 需要 给 createStateless() 提供 一 个 
lambda 表达 式 : 对 于 请 求 的 每 个 事件 ， 它 都 会 进行 调用 。 如 果 下 游 调用 request(3) ， 这 个 
自 定义 的 表达 式 就 会 被 调用 三 次 ， 这 里 假设 每 次 只 发 布 一 个 事件 。 在 每 次 调用 之 间 没 有 上 
下 文 (状态 )， 因 此 它 被 称 为 无 状态 的 。 
现在 ， 构 建 一 个 有 状态 的 操作 符 。Synconsubscribe 的 这 个 变种 允许 在 各 种 调用 间 传 递 一 个 
不 可 变 的 状态 变量 。 同 时 ， 每 次 调用 必须 要 返回 一 个 新 的 状态 值 。 样 例会 构建 一 个 从 零 开 
始 的 无 限 自然 数 生成 器 。 如 果 你 想 使 用 单调 递增 的 自然 数 来 压缩 一 个 任意 长 的 序列 ， 这 样 
的 操作 符 是 非常 有 用 的 。range() 也 能 很 好 地 运行 ， 但 是 它 需 要 提供 一 个 上 限 ， 在 有 些 情 
况 下 ， 这 可 能 不 太 实 用 ， 如 下 所 示 。 
Observable.OnSubscribe<Long> onSubscribe = 
SyncOnSubscribe.createStateful( 
() -> 0L， 
(cur, observer) -> { 


observer .onNext(cur); 
return cur + 1; 




































































); 
Observable<Long> naturals = Observable.create(onSubscribe); 


这 里 为 createStatefuL() 工厂 方法 提供 了 两 个 lambda 表达 式 。 第 一 个 表达 式 以 延迟 执行 
的 方式 创建 了 一 个 初始 状态 ， 在 本 例 中 这 个 状态 就 是 零 。 第 二 个 表达 式 更 加 重要 : 它 基 于 
当前 的 状态 ， 按 照 某 种 方式 推送 一 个 条 目 到 下 游 ， 并 返回 一 个 新 的 状态 值 。 这 个 状态 应 该 
是 不 可 变 的 ， 所 以 这 个 方法 允许 返回 一 个 新 的 状态 ， 而 不 是 改变 当前 的 状态 。 你 可 以 很 
容易 地 重 写 naturals 0bservablte， 让 它 返回 BigInteger， 避 免 可 能 会 出 现 的 溢出 。 这 个 
Observable 可 以 生成 任意 数量 的 递增 自然 数 ， 但 是 它 完 全 支持 回 压 。 这 意味 着 它 可 以 基于 
Subscriber 的 需求 ， 调 整 事件 的 生成 速度 。 与 原始 的 实现 方式 相 比 ， 确 实 会 简单 得 多 ， 但 
是 遇 到 缓慢 的 Subcriber 时 ， 它 就 暴露 出 不 足 了 。 
Observable<Long> naturals = Observable.create(subscriber -> { 
Long cur = 0; 
while (!subscriber.isUnsubscribed()) { 


System.out.println("Produced: " + cur); 
subscriber .onNext(cur++); 






































如 果 你 希望 使 用 单个 状态 变量 ， 这 个 变量 在 遍历 的 时 候 能 够 进行 改变 (如 JDBC 中 的 
ResultSet)，SyncOnSubscribe 同样 也 为 你 提供 了 一 个 方法 。 如 下 的 代码 由 于 检查 型 异常 无 
法 编译 通过 ， 但 是 这 里 只 想 强 调整 体 的 使 用 模式 。 


ResultSet resultSet = //... 








Observable.OnSubscribe<0bject[]> onSubscribe = SyncOnSubscribe.createSingleState( 
() -> resultSet, 
(rs，observer) -> { 
if (rs.next()) { 
observer .onNext(toArray(rs)); 
} else { 
observer .onCompleted(); 


} 


observer .onNext(toArray(rs)); 


}， 


ResultSet: :close 


); 
Observable<0bject[]> records = Observable.create(onSubscribe); 
这 里 有 三 个 回调 需要 实现 。 
。 状态 的 生成 器 。 这 个 lambda 表达 式 只 会 被 调用 一 次 ， 用 于 生成 状态 变量 ， 这 个 变量 将 
会 作为 参数 传递 给 后 续 的 表达 式 。 
。 生成 下 一 个 值 的 回调 ， 此 时 通常 会 基于 当前 状态 来 生成 下 一 个 值 。 这 个 回调 可 以 自由 地 
改变 第 一 个 参数 给 定 的 状态 。 
。 第 三 个 回调 会 在 取消 订阅 时 调用 ， 这 里 用 来 清理 ResuLtSet。 


具备 错误 处 理 功 能 的 更 加 完整 的 实现 如 下 所 示 。 注 意 ， 在 取消 订阅 时 发 生 的 错误 很 难 恰当 
地 传递 到 下 游 中 。 
Observable.OnSubscribe<Object[]> onSubscribe = SyncOnSubscribe.createSingleState( 
() -> resultSet, 
(rs, observer) -> { 
try { 
rs.next(); 
observer .onNext(toArray(rs)); 
} catch (SQLException e) { 
observer .onError(e); 





























} 
}， 
rs ->{ 
try { 
// 同 时 要 关闭 Statement、Connection 等 
rs.close(); 
} catch (SQLException e) { 
log.warn("Unable to close", e); 
} 
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SyncOnsubscribe 是 一 个 非常 便利 的 工具 集 ， 它 允许 编写 支持 回 压 的 Observable。“ 相对 于 
Observable.create()， 它 会 更 复杂 一 些 ,但 是 每 个 Subscriber 控制 回 压 带 来 的 收益 也 不 能 
低估 。 避 免 直接 使 用 create() 操作 符 ， 我 们 应 该 考虑 使 用 内 置 的 工厂 方法 ， 如 from() 或 


SyncOnSubscribe。 


回 压 能 够 通过 Subscriber 对 0bservable 进行 节 流 ， 这 是 一 个 非常 强大 的 机 制 。 这 样 的 反 
馈 通 道 显然 会 带 来 一 定 的 开销 ， 但 是 既 能 保证 松 耦 合 又 能 管理 生产 者 和 消费 者 ， 这 有 着 巨 
大 的 优势 。 回 压 通 常 伴随 着 批 处 理 ， 所 以 额外 的 开销 已 经 最 小 了 。 但 是 如 果 Subscriber 非 
常 缓慢 〈 甚 至 短暂 ) ， 这 种 缓慢 会 立即 体现 出 来 ， 整 个 系统 的 稳定 性 都 会 受到 牵连 。 使 用 
onBackpressure*() 家 族 方法 可 以 在 一 定 程度 上 迁移 不 支持 回 压 的 Observable， 但 这 并 不 是 
长 久之 计 。 


创建 自己 的 0bservable 时 ， 要 正确 地 处 理 回 压 请 求 。 毕 竞 我 们 无 法 控制 Subscriber 的 
否 吐 量 。 另 外 一 项 技术 是 避免 在 Subscriber 中 执行 重量 级 的 任务 ， 而 应 该 将 其 放 到 
flatMap() 中 。 例 如 ， 与 其 在 subscribe() 中 进行 数据 库存 储 的 操作 ， 我 们 不 如 这 样 做 ， 如 
下 所 示 。 


source.subscribe(this::store); 


应 该 孝 虑 让 store 更 加 符合 反应 式 的 要 求 ( 让 它 返 回 已 保存 记录 的 0bservabLe<UUID>) ， 并 
且 只 订阅 触发 订阅 和 副作用 。 
source 


.flatMap(this: :store) 
.Subscribe(uuid -> Log.debug("Stored: {}", uuid)); 


或 者 更 进一步 ， 批 量 获 取 UUID 以 减少 日 志 框 架 的 开销 。 


source 
.flatMap(this: :store) 
.buffer(100) 
.Subscribe( 
hundredUuids -> log.debug("Stored: {}", hundredUuids)) 


避免 在 subscribe() 中 执行 长 时 间 运 行 的 任务 ， 能 够 减少 回 压 的 需求 ， 但 是 预先 考虑 回 压 
依然 是 个 很 好 的 做 法 。 请 参考 JavaDoc 以 了 解 操作 符 是 否 支持 回 压 ， 如 果 操 作 符 缺 少 这 样 
的 信息 ， 很 可 能 就 不 会 受到 回 压 的 影响 ， 比 如 map()。 


6.3 ”小结 


本 章 的 一 个 重要 结论 就 是 要 避免 使 用 0bservable.create() 和 手动 发 布 事件 。 如 果 必 须 自 
己 实现 Observable， 请 考虑 使 用 支持 回 压 功能 的 工厂 方法 。 同 时 ， 要 关注 你 的 领域 ， 也 许 
可 以 安全 地 跳 过 事件 或 对 事件 进行 批 处 理 ， 以 减少 消费 端的 整体 负载 。 
























































































































































注 4: 如 果 你 需要 一 个 更 具 反 应 式 的 工具 集 ， 请 核查 AsyncOnsubscribe， 原 则 上 它 非 常 相似 ， 但 是 为 Observer 
生成 下 一 个 条 目的 回调 也 可 以 是 异步 的 。 
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本 书 读 到 现在 ， 相 信 你 已 经 理解 了 使 用 Reactive Extensions 进行 编程 的 基本 原则 。 到 目前 
为 止 ， 本 书 已 经 介绍 了 订阅 、 常 用 的 操作 符 、 在 已 有 的 应 用 程序 中 使 用 RxJava， 以 及 如 何 
写 完整 的 反应 式 软件 栈 。 但 是 ， 为 了 发 挥 反 应 式 编程 的 最 大 威力 ， 我 们 必须 更 进一步 。 
本 章 将 会 关注 一 些 不 常见 但 是 同样 重要 的 方面 和 原则 ， 如 下 所 示 。 

声明 式 的 错误 处 理 ， 包 括 重 试 (参见 7.1 节 )。 

虚拟 时 间 和 测试 (参见 7.2.1 市 )。 
。 监控 和 调试 Observable 流 (参见 7.4 市 )。 


如 果 要 将 一 个 库 或 框架 成 功 部 署 到 生产 环境 中 ， 仅 仅 理解 它 是 不 够 的 。 如 果 你 想 构建 可 
靠 、 稳定 且 有 弹性 的 应 用 程序 ， 上 述 各 个 方面 都 至 关 重 要 。 


十 * 口 

7.1 错误 处 理 
反应 式 宣言 列举 了 反应 式 系统 应 该 具备 的 4 个 特征 : 即时 响应 性 (responsive) 、 回 弹性 
(resilient) 、 弹 性 (elastic) 和 消息 驱动 (message driven) 。 看 一 下 其 中 两 个 特征 。 
口 即时 响应 性 

只 要 有 可 能 ， 系 统 就 会 及 时 地 做 出 响应 。[…] 即时 响应 意味 着 可 以 快速 检测 到 问题 ， 
并 且 进 行 有 效 地 处 理 。[…] 快速 而 一 致 的 响应 时 间 ，[…] 简化 错误 处 理 。 
口 回 弹 性 

系统 在 出 现 失 败 时 依然 要 保持 即时 响应 性 。[…] 系统 某 部 分 的 失败 不 会 危及 整个 系统 ， 
并 能 独立 恢复 。[…] 组 件 的 客户 端 不 再 承担 组 件 失 败 处 理 的 任务 。 
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本 节 将 会 阐述 即时 响应 性 和 回 弹性 为 何如 此 重要 ， 以 及 RxJava 是 如 何 帮助 实现 它们 的 。 
现在 ， 你 已 经 非常 熟悉 在 订阅 Observable 的 时 候 使 用 onError() 回调 。 但 这 只 是 冰山 一 
角 ， 而 且 通 常 不 是 处 理 错 误 的 最 佳 方式 。 


7.1.1 我 的 异常 在 哪里 
在 传统 的 Java 中 ， 错 误 通 常用 异常 来 表示 。Java 中 有 以 下 两 种 类 型 的 异常 。 


非 检查 型 异常 ， 这 种 异常 在 方法 声明 上 不 需要 体现 出 来 。 如 果 某 个 方法 抛 出 非 检查 型 异 
第 (比如 NullPointerException)， 可 以 在 方法 声明 上 标记 该 异常 ， 但 这 并 不 是 强制 的 。 
检查 型 异常 ， 为 了 保证 代码 通过 编译 ， 这 种 异常 必须 要 声明 和 处 理 。 基 本 上 ， 这 是 所 有 
未 扩展 RuntimeException 或 Error 和 的 Throwable， 比 如 IOException。 


这 两 种 传统 异常 处 理 方式 各 有 利 次。 非 检 查 型 异常 很 容易 添加 进来 ， 并 且 不 会 破坏 编译 时 
的 向 后 兼容 性 。 同 时 ， 使 用 非 检查 型 异常 时 ， 客 户 端 代码 看 上 去 会 更 整洁 ， 因 为 它 不 需要 
进行 错误 处 理 (尽管 它 可 以 这 样 做 )。 而 检查 型 异常 更 明确 地 说 明了 方法 预期 的 输出 。 当 
然 ， 每 个 方法 可 以 抛 出 任意 类 型 ， 但 是 检查 型 异常 被 视 为 API 的 一 部 分 ， 明 确 指出 了 必 
须 处 理 的 错误 。 尽 管 检 查 型 异常 无 法 被 忽略 ， 而 且 在 编写 无 错误 的 代码 方面 似乎 更 具 优 
势 ， 但 是 事实 证 明 ， 它 们 非常 笨拙 和 上 罗 浴 。 即 便 是 官方 的 Java API 也 正在 迁移 至 非 检查 型 
异常 。 例 如 ， 旧 的 JMSException (检查 型 ) 在 JMS 2.0 中 变 成 了 新 的 J]MSRuntimeException 
( 非 检查 型 ) 。 


RxJava 采取 了 一 种 完全 不 同 的 方式 。 首 先 ， 在 标准 的 Java 中 ， 异 常 是 类 型 系统 中 的 
一 个 新 维度 。 方 法 有 一 个 返回 类 型 ， 同 时 还 有 与 之 完全 正 交 的 异常 。 某 个 方法 打开 一 
个 File 时 ， 它 可 能 会 返回 InputSstream， 也 可 能 会 抛 出 FileNotFoundException。 但 是 ， 
FileNotFoundException 没有 声明 会 怎么 样 呢 ? 或 者 说 ， 是 否 还 要 预期 出 现 其 他 异常 ? 异 
常 就 像 男 外 一 条 执行 路 径 ， 正 如 失败 始终 是 意料 之 外 的 事情 一 样 ， 异 常 也 永远 不 会 是 正常 
业务 流 的 一 部 分 。 在 RxJava 中 ， 失 败 是 另外 一 种 类 型 的 通知 。0bservable<T> 都 是 T 类 型 
的 事件 序列 ， 后 面 跟随 可 选 的 完成 或 失败 通知 。 这 意味 着 错误 隐 式 地 变 成 了 每 个 流 的 一 部 
分 ， 即 便 不 需要 对 其 进行 处 理 ， 很 多 操作 符 也 能 够 以 更 加 稳定 的 方式 声明 式 地 处 理 错误 。 
同时 ， 在 Observable 周围 贸然 添加 try-catch 并 不 会 捕获 到 任何 错误 ， 这 些 错误 只 能 通过 
上 述 的 错误 通知 进行 传递 。 

但 是 ， 在 探讨 如 何 通 过 RxJava 操作 符 声 明 式 地 处 理 错误 之 前 ， 我 们 必须 要 理解 错误 在 完 
全 不 进行 处 理 时 使 用 启发 式 的 行为 。 在 Java 中 ， 异 常 可 能 会 在 任意 地 方 出 现 。 库 的 作者 必 
须 确保 错误 得 到 了 恰当 的 处 理 ， 如 果 不 进行 处 理 ， 至 少 也 要 进行 报告 。 使 用 subscribe() 
最 常见 的 问题 就 是 没有 定义 onError 回调 。 

Observable 


.Create(subscriber -> { 


try { 
subscriber .onNext(1 / 0); 
} catch (Exception e) { 
subscriber .onError(e); 






























































































































































// 有 问题 的 ， 缺 少 onError() 回 调 


.Subscribe(System.out::println); 





在 create() 中 ， 样 例 强 制 抛 出 ArithmeticException 并 调用 每 个 Subscriber 的 onError() 回 
调 。 但 是 ， 令 人 遗憾 的 是 ，subscribe() 根本 没有 提供 onError() 实现 。 不 过 ，RxJava 会 努 
力 扭转 败局 ， 它 会 抛 出 包装 原始 ArithmeticException 的 OnErrorNotImplementedException。 
但 是 ， 由 哪个 线程 抛 出 这 个 异常 呢 ? 这 个 问题 很 难 回 答 。 如 果 0bservable 是 同步 的 (如 
前 面 的 样 例 所 示 ) ， 那 么 客户 端 线程 将 会 间接 调用 create()， 因 此 会 在 没有 处 理 onError() 
的 时 候 抛 出 OnErrorNotImplementedException。 这 意味 着 调用 subscribe() 的 线程 将 接收 到 


OnErrorNotImpLementedException。 


如 果 你 忘记 订阅 错误 而 且 0bservable 是 异步 的 ， 那 情况 就 变 得 更 加 复杂 了 。 这 时 抛 出 
OnErrorNotImpLementedException， 调 用 subscribe() 的 线程 可 能 早 就 消失 了 。 在 这 种 情况 
下 ， 异 常会 在 准备 调用 onError() 回调 的 线程 中 抛 出 。 这 可 能 是 通过 subscribeon() 或 最 
后 一 个 observeon() 选择 的 来 自 Scheduler 的 线程 。Scheduter 可 以 按照 任意 方式 管理 这 种 
预料 之 外 的 异常 ， 大 多 数 情况 下 ， 它 只 是 将 堆栈 跟踪 打印 到 标准 错误 流 中 。 这 远 远 称 不 上 
完美 的 方案 : 这 样 的 异常 绕 过 了 正常 日 志 代 码 ， 其 至 会 被 忽略 。 因 此 ，subscribe() 只 监 
昕 值 而 忽略 错误 通常 是 一 个 不 好 的 信号 ， 可 能 会 丢失 错误 。 即 便 预 期 不 会 发 生 任何 异常 
(这 种 情况 非常 罕见 ) ， 至 少 也 应 该 将 错误 日 志 揪 入 日 志 框架 。 


private static final Logger Log = LoggerFactory.getLogger(My.class); 
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.SUbscribe( 
System.out: :println, 
throwable -> log.error("That escalated quickly", throwable)); 


还 有 很 多 其 他 的 地 方 可 能 会 产生 异常 或 者 不 经 意 间 将 异常 引入 进来 。 首 先 ， 在 create() 中 
使 用 try-catch() 代码 块 将 lambda 表达 式 包 装 起 来 ， 通 常 是 一 种 好 的 实践 ， 比 如 在 上 面 的 
样 例 中 使 用 以 下 代码 。 


Observable.create(subscriber -> { 
try { 
subscriber .onNext(1 / 0); 
} catch (Exception e) { 
subscriber .onError(e); 




















} 
}); 


但 是 ， 如 果 你 忘记 使 用 try-catch 并 让 create() 抛 出 异常 ，RxJava 会 竭尽 所 能 地 将 异常 以 
onError() 通知 的 形式 进行 传递 。 

Observable.create(subscriber -> subscriber.onNext(1 / 0)); 
上 面 的 两 个 代码 样 例 在 语义 上 是 等 价 的 。create() 抛 出 的 异常 在 内 部 会 被 RxJava 捕获 并 
转换 成 错误 通知 。 不 过 ， 还 是 建议 尽 可 能 通过 subscriber.onError() 显 式 地 传递 异常 。 更 
好 的 方法 是 使 用 fromCallable()。 


Observable.fromCallable(() -> 1 / 0); 
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其 他 可 能 生成 异常 的 是 接收 用 户 代 码 的 各 种 操作 符 。 简 而 言 之 ， 就 是 接收 lambda 表达 式 
EF 为 参数 的 备 种 操作 符 ， 比 如 map()、filter()、zip() 等 。 这 些 操作 符 不 仅 要 处 理 来 自 上 
游 observable 的 错误 通知 ， 还 要 处 理 自 定义 映射 函数 或 断言 抛 出 的 异常 。 以 下 面 这 个 有 问 
题 的 映射 和 过 滤 为 例 。 

Observable 


.just(1, 0) 
.map(x -> 10 / x); 








一 、 


























Observable 
.just("Lorem", null, "ipsum") 
.filter(String::isEmpty); 


对 于 某 些 元 素 ， 第 一 个 例子 抛 出 了 ArithmeticException。 在 第 二 个 例子 中 ， 调 用 filter() 
断言 时 ， 会 导致 NullPointerException。 传 递 给 高 阶 函 数 (如 map() 和 fitter()) 的 
lambda 表达 式 都 应 该 是 纯 表达 式 ， 而 抛 出 异常 是 一 种 不 纯粹 的 副作用 。 在 这 里 ，RxJava 会 
再 次 竭力 处 理 预料 之 外 的 异常 ， 而 且 它 的 行为 符合 预期 。 如 果 管 道中 的 任意 操作 符 抛 出 异 
常 ， 它 会 被 转换 成 错误 通知 并 传递 到 下 游 中 。 尽 管 RxJava 试图 去 修复 有 问题 的 用 户 代 码 ， 
如 果 lambda 表达 式 有 抛 出 异常 的 可 能 ， 那 么 我 们 应 该 使 用 flatMap() 进行 显 式 声明 。 
Observable 
.just(1, 0) 
.flatMap(x -> (x == 0) ? 


Observable.error(new ArithmeticException("Zero :-(")) : 
Observable.just(10 / x) 














); 


flatMap() 操作 符 用 途 非 常 广泛 ， 它 不 需要 指明 异步 计算 的 下 一 步 要 做 什么 。0bservable 
是 一 个 包含 值 或 错误 的 容器 ， 所 以 如 果 你 想 要 声明 式 地 表达 即便 非常 快速 的 计算 也 有 可 能 
产生 错误 ， 那 么 使 用 0bservable 包装 也 是 一 个 不 错 的 可 选 方案 。 


7.1.2 ”替代 声明 式 的 try-catch 

错误 与 流 经 observable 管道 的 正常 事件 非常 相似 。 理 解 了 错误 来 自 何方 ， 接 下 来 就 要 学 习 
如 何 声明 式 地 对 其 进行 处 理 。 我 们 使 用 的 observabte 通常 是 多 个 操作 符 和 上 游 0bservabte 
的 组 合体 。 以 下 样 例 是 基于 某 些 数据 构建 保险 协议 的 过 程 。 


Observable<Person> person = //... 
Observable<InsuranceContract> insurance = //... 
Observable<Health> health = person.flatMap(this::checkHealth); 
Observable<Income> income = person.flatMap(this::determineInNncome); 
Observable<Score> score = Observable 

.Zip(health, income, (h, i) -> asses(h, i)) 

.map(this::translate); 
Observable<Agreement> agreement = Observable.zip( 

insurance, 

score.filter(Score::isHigh), 

this: :prepare); 
Observable<TrackingId> mail = agreement 

.filter(Agreement: :postalMailRequired) 
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.flatMap(this: :print) 
.flatMap(printHouse: :deliver); 


这 个 略 显 牵强 的 样 例 展 现 了 业务 处 理 的 几 个 步骤 。 首 先 ， 样 例 加 载 Person， 查 找 可 用 的 
InsuranceContract， 基 于 Person 确认 Health 和 Income (并 发 分 又 执行 )。 然 后 ， 样 例 将 这 
两 个 结果 联合 起 来 进行 计算 并 转换 成 Score。 最 后 ，InsuranceContract 与 Score 〈 仅 在 它 
的 值 比较 高 的 情况 下 ) 联合 起 来 ， 并 执行 一 些 后 置 的 处 理 ， 比 如 发 送 邮件 。 你 应 该 知道 ， 
到 此 为 止 ， 其 实 什 么 都 没有 开始 执行 。 样 例 只 是 定义 了 要 进行 的 操作 ， 在 真正 有 人 订阅 之 
前 ， 不 会 执行 任何 业务 逻辑 。 但 是 ， 如 果 某 一 个 上 游 源 出 现 了 错误 通知 又 会 怎样 呢 ? 这 里 
没有 可 见 的 错误 处 理 ， 但 是 错误 能 够 非常 便利 地 进行 传递 。 
目前 见 过 的 所 有 操作 符 主要 是 作用 于 值 的 ， 完 全 忽略 了 错误 。 这 样 也 是 可 以 的 :普通 的 操 
作 符 将 流 经 的 值 进 行 转换 ， 但 是 会 跳 过 完成 和 错误 通知 ， 让 它们 往 下 游 流动 。 这 意味 着 任 
意 上 游 0bservable 的 单个 错误 会 与 级 联 失败 一 起 传递 给 所 有 下 游 的 订阅 者 。 再 次 强调 ， 如 
果 业 务 逻 辑 需 要 所 有 的 步骤 都 成 功 ， 这 种 方式 是 没有 问题 的 。 但 是 ， 在 有 些 情况 下 ， 你 可 
以 安心 地 忽略 失败 ， 并 将 其 替换 为 备用 值 或 次 级 源 。 
1. 使 用 onErrorReturn() 将 错误 替换 为 固定 的 结果 
在 RxJava 中 ， 最 简单 的 错误 处 理 操 作 符 是 onErrorReturn(): 过 到 错误 的 时 候 ， 会 使 用 一 
个 固定 的 值 来 进行 替换 。 

Observable<Income> income = person 


.flatMap(this: :determineIncome) 
.ONErrorReturn(error -> Income.no()) 
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private Observable<Income> determineIncome(Person person) { 
return Observable.error(new RuntimeException("Foo")); 


} 


class Income { 
static Income no() { 
return new Income(0); 
} 
} 


onErrorReturn() 操作 符 其 至 都 不 需要 解释 。 正 常 的 事件 通过 时 ， 这 个 操作 符 不 会 做 任何 事 
情 。 但 是 ， 接 收 到 来 自 上 游 的 错误 通知 时 ， 它 会 立即 丢弃 错误 并 替换 为 一 个 固定 值 一 一 在 
本 例 中 是 Income.no()。 相 对 于 按照 命令 式 的 风格 在 try-catch 代码 块 的 catch 语句 中 返回 
固定 值 ，onErrorReturn() 是 一 个 非常 流畅 且 易 读 的 替代 方案 。 


try { 
return determineIncome(Person person) 


} catch(Exception e) { 
return Income.no(); 


} 


在 本 例 中 ，catch 语句 吞噬 了 原始 的 异常 ， 并 且 返 回 了 一 个 国定 值 。 可 能 它 就 是 这 样 设 
计 的 ， 但 通常 比较 好 的 做 法 是 在 异常 发 生 时 至 少 进行 日 志 记录 。RxJava 中 的 所 有 错误 处 
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悍 操 作 符 的 都 是 这 样 表现 的 : 如 果 已 经 显 式 处 理 某 些 异 常 ， 那 么 该 异常 会 被 吞噬 。 这 是 
你 确实 需要 考虑 的 ， 如 果 故 障 系 统 的 日 志文 件 没 有 暴露 任何 的 问题 ， 那 可 以 说 是 最 糟糕 
的 事情 了 。onErrorReturn() 将 错误 作为 参数 传递 了 过 来 ， 但 是 却 被 忽略 了 。 你 可 以 在 
onErrorReturn() 中 记录 异常 ， 也 可 以 使 用 更 加 专业 的 诊断 操作 符 ，7.4 而 将 对 此 进行 介绍 。 
现在 ， 只 需要 记 住 ，RxJava 中 的 所 有 操作 符 都 将 异常 记录 和 监控 的 任务 留 给 了 我 们 。 


2. 使 用 onErrorResumeNext() 延 迟 计算 备用 值 
使 用 onErrorReturn() 返回 一 个 固定 值 有 时 是 一 种 很 好 的 方式 ， 但 通常 我 们 想 要 在 出 现 错 
误 时 延迟 计算 出 备用 值 。 以 下 是 两 种 可 能 的 场景 。 


。 生成 数据 流 的 主要 方式 失败 了 (发 生 了 onError() 事件 ) ， 所 以 切换 到 同样 非常 好 的 备 
用 产 上 ， 但 是 因为 某 种 原因 ， 我 们 将 其 视 为 备用 方案 〈 比 如 该 方案 更 慢 、 代 价 更 高 等 ) 。 

。 出 现 失败 的 时 候 ， 我 们 想 要 将 真实 的 数据 替换 为 代价 更 低 、 稳 定性 更 好 的 ， 但 可 能 有 些 
陈旧 的 信息 。 比 如 ， 检 索 新 数据 失败 的 时 候 ， 可 能 会 从 缓存 中 选择 较为 陈旧 的 流 。 另 一 
个 常见 样 例 可 能 会 带 来 稍 差 的 用 户 体验 。 例 如 ， 在 线 商城 中 会 返回 全 局 最 畅销 的 商品 ， 
而 不 是 个 性 化 推荐 的 商品 。 


































































































显然 ， 错 误 发 生 时 需要 的 逻辑 本 身 可 能 代价 非常 高 员 ， 而 且 可 能 会 出 错 。 因 此 ， 必 须 将 备 
用 逻辑 封装 到 一 个 延迟 执行 的 包装 器 中 ， 并 且 最 好 是 异步 的 。 这 样 的 包装 器 会 是 什么 样 ? 








当然 是 Observable | 


Observable<Person> person = //... 

Observable<Income> income = person 
.flatMap(this: :determineIncome) 
.ONErrorResumeNext(person.flatMap(this::guessIncome)); 


Va 


private Observable<Income> guessIncome(Person person) { 
/fi 
} 


onErrorResumeNext() 操作 符 基 本 上 就 是 将 错误 通知 替换 成 了 另外 一 个 流 。 如 果 你 订阅 了 某 个 
使 用 onErrorResumeNext() 作为 防护 措施 的 Observable，RxjJava 会 透明 地 从 主 0bservabte 切 
换 到 备用 0bservable (指定 为 参数 )。 在 样 例 中 ， 如 果 income 流失 败 ， 错 误 通知 会 被 捕获 ， 
库 会 自动 订阅 guessIncome() 流 。 这 个 流 可 能 不 那么 精确 ， 但 是 更 加 可 靠 、 迅 速 或 低 成 本 。 
有 意思 的 是 ，onErrorResumeNext() 可 以 赫 换 成 concatwith()， 假设 determineIncome 会 且 
仅 会 发 布 一 个 值 或 错误 。 


Observable<Income> income = person 

.flatMap(this::determineIncome) 
.flatMap( 

Observable::just, 

th -> Observable.empty(), 

Observable: :empty) 
.concatWith(person.flatMap(this::guessIncome)) 
.first(); 


flatMap() 操作 符 有 个 不 常见 的 地 方 ， 它 接收 三 个 lambda 表达 式 而 不 是 一 个 。 
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。 第 一 个 参数 允许 将 上 游 0bservabte 中 的 每 个 元 素 替 换 为 新 的 0bservable， 这 是 本 书 中 
flatMap() 一 直 以 来 的 用 法 。 

。 第 二 个 参数 将 可 能 会 出 现 的 错误 通知 替换 为 另外 一 个 流 。 我 们 想 要 忽略 上 游 的 错误 ， 所 
以 在 这 里 只 切换 为 一 个 空 的 Observable。 

。 最 后 ， 上 游 正 常 完成 时 ， 完 成 通知 可 以 替换 为 另外 一 个 流 。 

first() 操作 符 在 这 里 的 使 用 至 关 重 要 。 使 用 first() 操作 符 表 明 只 想 获 取 第 一 个 出 现 的 

事件 。 在 成 功 的 情况 下 ， 我 们 会 得 到 determineIncone 的 结果 ， 而 RxJava 永远 不 会 订阅 

guessIncome() 的 结果 。 但 是 出 现 失败 的 时 候 ， 第 一 个 Observable 实际 上 没有 发 布 任何 事 

件 ， 所 以 first() 会 请 求 其 他 条 目 ， 此 时 就 会 使 用 订阅 的 备用 流 ， 这 个 流 作为 参数 传递 给 

concatWith()。 


到 这 里 ， 相 信 你 已 经 意识 到 本 例 中 的 concatwtth() 并 不 是 真正 必要 的 ， 最 复杂 形式 的 
flatMap() 就 足够 了 。 即 便 first() 也 并 非 必须 要 有 。 思 考 如 下 的 代码 。 
Observable<Income> income = person 
.flatMap(this: :determineIncome) 
.flatMap( 
Observable: :just, 
th -> person.flatMap(this::guessIncome), 
Observable: :empty); 


上 述 的 样 例 有 一 个 非常 有 意思 的 特性 ， 基于 Throwable 类 型 的 th， 可 以 返回 onError() 映 
射 中 一 个 不 同 的 0bservabLe。 所 以 理论 上 能 够 基于 异常 信息 或 类 型 ， 返 回 不 同 的 备用 流 。 
onErrorResumeNext() 操作 符 有 一 个 重 载 版 本 ， 能 够 实现 这 样 的 功能 。 
Observable<Income> income = person 
.flatMap(this: :determineIncome) 
.OnErrorResumeNext(th -> { 
if (th instanceof NullPointerException) { 
return Observable.error(th); 
} elsef{ 
return person.fLatMap(this::guessIncome); 
} 
]); 
尽管 flatMap() 的 用 途 非常 广泛 ， 能 够 提供 灵活 的 错误 处 理 功能 ;但 是 onErrorResumeNext() 
的 表述 性 更 好 ， 代 码 更 易于 阅读 。 所 以 我 们 应 该 优先 使 用 后 者 。 


7.1.3 事件 没有 发 生 导 致 的 超时 

RxJava 提供 了 一 些 操作 符 来 处 理 上 游 0bservable 的 异常 通知 。 但 是 ， 你 知道 比 错误 更 粳 
糕 的 情况 是 什么 吗 ? 静默 ! 要 连接 的 系统 因为 出 现 了 异常 而 失败 ， 这 相对 来 说 更 容易 进行 
预测 、 处 理 、 单 元 测试 等 。 但 是 ， 如 果 你 订阅 了 一 个 Observable， 本 来 预期 能 够 立即 得 到 结 
果 , 但 是 它 却 迟 述 不 发 布 任何 内 容 ， 那 么 你 该 怎么 办 ?这 种 场景 比 简单 地 出 现 错 误 精 糕 得 
多 。 系 统 的 延迟 会 受到 严重 影响 ， 系 统 似乎 被 挂 起 了 ,但 是 日 志 中 没有 任何 清晰 的 标记 。 


幸而 ，RxJava 提供 了 一 个 内 置 的 timeout() 操作 符 监 听 上 游 的 0bservable， 它 会 持续 监控 
自 上 一 个 事件 发 布 或 Observable 订阅 以 来 ， 经历 了 多 长 时 间 。 如 果 连 续 事 件 之 间 的 静默 
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时 间 超 出 了 给 定 的 时 间 段 ，timeout() 操作 符 会 发 布 一 个 包含 TimeoutException 的 错误 通 
知 。 为 了 更 好 地 理解 timeout() 是 如 何 运 行 的 ， 首 先 考 虑 在 特定 时 间 之 后 只 发 布 一 个 事件 
的 Observable。 为 了 方便 阐述 ， 我 们 将 会 创建 一 个 Observable， 它 会 在 200 毫秒 之 后 返回 
Confirmation 事件 。 通 过 添加 delay(109，MILLISECONDS) 模拟 延迟 。 除 此 之 外 ， 我 们 还 想 
要 在 事件 和 完成 通知 之 间 模 拟 额外 的 延迟 。 这 正 是 使 用 empty() 0bservablte 的 目的 所 在 ， 
正常 情况 下 ， 它 会 立即 完成 ;但 是 因为 额外 的 delay()， 发 送 完 成 通知 之 前 会 进行 等 待 。 
将 这 两 个 流 组 合 起 来 之 后 ， 效 果 如 下 。 
Observable<Confirmation> confirmation() { 
Observable<Confirmation> delayBeforeCompletion = 
Observable 
.<Confirmation>empty() 
.delay(200, MILLISECONDS); 
return Observable 
.just(new Confirmation()) 


.delay(100, MILLISECONDS) 
.Concatwith(delayBeforeCompletion); 


















































} 
现在 ,测试 一 下 按照 最 简单 的 重 载 版 本 驱动 ttmeout() 操作 符 。 


import java.util.concurrent.TimeoutException; 


/11... 


confirmation() 
.timeout(210, MILLISECONDS) 
.forEach( 
System.out: :println, 
th -> { 
if ((th instanceof TimeoutException)) { 
System.out.println("Too long"); 
} else { 
th.printStackTrace(); 
} 
} 
); 
这 里 使 用 210 毫秒 的 超时 并 不 是 巧合 。 从 开始 订阅 到 confirmation 实例 到 达 的 时 间 间 隔 恰 
好 是 100 毫秒 ， 小 于 超时 的 国 值 。 另 外 ， 这 个 事件 和 完成 通知 之 间 的 延迟 是 200 毫秒 ， 依 
然 小 于 210。 因 此 ， 在 本 例 中 ，timeout() 操作 符 是 透明 的 ， 并 不 会 影响 整个 消息 流 。 但 
是 ， 如 果 timeout() 的 国 值 调整 为 略 小 于 200 毫秒 (假设 为 190 毫秒 ) ， 那 么 它 的 作用 就 
体现 出 来 了 。Confirmation 展现 了 出 来 ， 但 是 完成 回调 没有 执行 ， 我 们 接收 到 了 一 个 包含 
TimeoutException 的 错误 通知 。 第 一 个 事件 抵达 的 延迟 远 小 于 200 毫秒 ， 而 第 一 个 事件 和 
第 二 个 事件 (实际 上 是 完成 通知 ) 之 间 的 延迟 超过 了 190 毫秒 ， 因 此 会 将 一 个 错误 通知 传递 
到 下 游 中 。 当 然 ， 如 果 把 超时 靖 值 设置 为 小 于 100 毫秒 ， 我 们 甚至 无 法 看 到 第 一 个 事件 。 
这 是 timeout() 最 简单 的 用 例 : 当 我 们 想 要 限制 等 待 响应 的 时 间 时 ， 就 会 发 现 它 非常 有 
用 。 但 有 的 时 候 ， 固 定 的 超时 国 值 过 于 严格 ， 而 我 们 可 能 想 要 在 运行 时 调整 超时 时 间 。 假 
设想 要 构建 一 个 预测 下 次 日 食 的 算法 。 算 法 的 接口 是 一 个 Observable<LocalDate> ( 理 
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应 如 此 )， 它 代表 了 此 类 事件 未 来 的 日 期 。 假 设 这 个 算法 是 计算 密集 类 型 的 ， 我 们 依然 
会 进行 模拟 ， 不 过 这 次 使 用 的 是 interval() 操作 符 (参见 2.4.3 节 )， 将 一 个 固定 的 日 
期 列表 和 interval() 生成 的 一 个 较 缓 慢 的 进度 流 合并 到 一 起 。 借 助 intervaL(500， 50， 
MILLISECONDS)， 第 一 个 日 期 会 在 500 毫秒 之 后 出 现 ， 后 续 的 每 个 日 期 会 在 50 毫秒 之 后 出 
现 。 在 现实 系统 中 ， 这 非常 常见 : 响应 的 第 一 个 元 素 会 有 比较 高 的 延迟 。 这 可 能 是 初始 化 
连接 、SSL 握手 、 查 询 优化 或 服务 器 端 要 执行 的 事情 导致 的 。 但 是 ， 后 续 的 事件 要 么 能 够 
轻而易举 获得 ， 要 么 很 容易 检索 ， 所 以 它们 之 间 的 延迟 要 低 得 多 。 


Observable<LocalDate> nextSolarEclipse(LocalDate after) { 
return Observable 

.just( 
LocalDate.of(2016, MARCH, 9),， 
LocalDate.of(2016, SEPTEMBER, 1), 
LocalDate.of(2017, FEBRUARY, 26), 
LocalDate.of(2017, AUGUST, 21), 
LocalDate.of(2018, FEBRUARY, 15), 
LocalDate.of(2018, JULY, 13), 
LocalDate.of(2018, AUGUST, 11), 
LocalDate.of(2019, JANUARY, 6), 
LocalDate.of(2019, JULY, 2), 
LocalDate.of(2019, DECEMBER, 26)) 

.SkipNhiLe(date -> !date.isAfter(after)) 

.ZipWith( 
Observable.interval(500, 50, MILLISECONDS), 
(date, x) -> date); 














} 
在 这 种 类 型 的 场景 下 ， 如 果 使 用 固定 的 国 值 就 是 有 问题 的 做 法 了 。 第 一 个 事件 应 该 使 用 较 
为 保守 的 限制 值 ， 而 后 续 事件 的 间隔 应 该 更 加 乐观 一 些 。 重 载 版 本 的 timeout() 恰好 能 够 
实现 这 一 点 : 它 会 接收 两 个 Observable 的 工厂 ， 一 个 会 生成 第 一 个 事件 的 超时 时 间 ， 另 一 
个 则 会 生成 后 续 元 素 的 超时 时 间 。 代 码 胜 千 言 ， 如 下 所 示 。 
nextSolarEclipse(LocalDate.of(2016, SEPTEMBER, 1)) 
.timeout( 
() -> Observable.timer(1000, TimeUnit.MILLISECONDS), 
date -> Observable.timer(100, MILLISECONDS)) 
在 这 里 ， 第 一 个 0bservable 会 在 1 秒 之 后 发 布 一 个 事件 ， 它 代表 了 第 一 个 事件 能 接受 的 延 
迟 国 值 。 第 二 个 0bservable 是 为 流 中 出 现 的 每 个 元 素 创建 的 ， 允 许 细 粒 度 地 控制 后 续 事件 
的 超时 。 注 意 ， 这 里 并 没有 使 用 date 参数 。 可 以 设想 一 下 在 某 种 场景 中 具备 自 适 应 能 力 的 
超时 时 间 ， 比 如 ， 如 果 上 一 个 延迟 比 以 往 更 长 ， 那 么 等 待 下 一 个 事件 时 ， 可 以 稍微 多 等 待 
一 些 时 间 。 或 者 ， 与 之 相反 ， 让 后 续 事件 的 超时 时 间 更 短 一 些 ， 以 适应 订阅 者 的 性 能 。 


在 有 些 情 况 下 ， 即 便 没 有 超时 ， 跟 踪 每 个 事件 的 延迟 也 是 非常 有 用 的 。 此 时 ， 可 以 使 用 非 
常 便 利 的 timeInterval() 操作 符 : 它 会 将 T 类 型 的 事件 替换 成 TimeIntervaL<T>。 后 者 会 
封装 事件 ， 但 是 也 会 显示 从 上 一 个 事件 开始 经 过 了 多 少时 间 (对 于 第 一 个 事件 ， 是 从 订阅 
开始 经 历 的 时 间 )。 

Observable<TimeInterval<LocalDate>> intervals = 


nextSolarEclipse(LocalDate.of(2016, JANUARY, 1)) 
.timeInterval(); 
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除了 能 够 返回 LocaLDate 实例 中 的 getValue() 方法 之 外 ，TimeInterval<LocalDate> 还 有 一 
个 getIntervalInMilliseconds()。 不 过 ,研究 一 下 上 述 程序 在 订阅 之 后 的 输出 ， 能 够 容易 
地 看 出 它 是 如 何 运 行 的 。 你 可 以 清晰 地 看 到 ， 第 一 个 事件 耗费 了 533 上 毫秒 才 出 现 ， 而 后 续 





的 每 个 事件 基本 只 需要 约 50 毫秒 。 


TimeInterval [intervalInMilliseconds=533, value=2016-03-09] 
TimeInterval [intervalInMilliseconds=49, value=2016-09-01] 
TimeInterval [intervalIinMilliseconds=50, value=2017-02-26] 
TimeInterval [intervalIinMilliseconds=50, value=2017-08-21] 
TimeInterval [intervalIinMilliseconds=50, value=2018-02-15] 
TimeInterval [intervalIinMilliseconds=50, value=2018-07-13] 
TimeInterval [intervalIinMilliseconds=50, value=2018-08-11] 
TimeInterval [intervalIinMilliseconds=50, value=2019-01-06] 
TimeInterval [intervalIinMilliseconds=51, value=2019-07-02] 
TimeInterval [intervalIinMilliseconds=49, valuye=2019-12-26] 





timeout() 还 有 一 个 重 载 版 本 ， 它 能 在 遇 到 错误 时 接收 一 个 备用 的 Observable 以 替代 初始 

















的 源 。 这 种 行为 与 onErrorResumeNext() 非常 类 似 (参见 7.4.2 节 )。 


7.1.4 失败 之 后 的 重 试 








onError 是 一 个 终结 通知 ， 意 味 着 在 这 个 流 中 不 会 出 现 其 他 事件 了 。 因 此 ， 如 果 你 想 要 标 
记 半 在 非 致 命 的 业务 条 件 ， 那 么 应 该 避免 使 用 onError。 这 与 通常 建议 避免 使 用 异常 来 控 
制程 序 流 并 没有 太 大 的 差异 。 相 反 ， 在 0bservable 中 ， 可 以 考虑 将 错误 包装 到 特殊 类 型 的 















































事件 中 ， 这 样 的 事件 能 够 随 着 正常 事件 多 次 出 现 。 例 如 ， 如 果 你 想 要 提供 一 个 由 交易 结果 














组 成 的 流 ， 但 是 有 些 交 易 可 能 会 因为 业务 原因 (比如 余额 不 足 ) 而 失败 。 
该 避免 使 用 onError 通知 。 相 反 ， 应 该 考虑 创建 一 个 TransactitonResutLt 才 








这 种 情况 下 ， 应 
由 象 类 ， 这 个 抽象 


类 可 以 有 两 个 具体 的 子 类 ， 分别 代表 成 功 和 失败 。 在 这 种 流 中 ，onError 通知 表示 出 现 了 











非常 严重 的 问题 ， 比 如 阻碍 后 续 事 件 发 布 的 灾难 性 故障 。 
也 就 是 说 ，onError 可 以 代表 外 部 组 件 或 系统 的 瞬时 故障 。 有 意思 的 是 ， 

















通常 简单 重 试 一 


次 就 能 成 功 了 。 其 他 的 系统 可 能 正在 经 历 短暂 的 负载 高 峰 、GC 暂停 或 重启 。 在 构建 健壮 
且 有 弹性 的 应 用 程序 时 ， 重 试 是 一 种 很 重要 的 机 制 。RxJava 对 重 试 提供 了 一 流 的 支持 。 


最 简单 版 本 的 retry() 操作 符 会 重新 订阅 失败 的 Onservable， 并 希望 它 能 继续 生成 正常 











的 事件 ， 而 不 是 再 次 出 现 失 败 。 出 于 教学 讲解 的 目的 ， 以 下 创建 一 个 


Observable, 





Observable<String> risky() { 
return Observable.fromCallable(() -> { 
if (Math.random() < 0.1) { 
Thread.sLeep((Long) (Math.random() * 2000)); 
return "OK"; 
} else { 
throw new RuntimeException("Transient"); 


存在 严重 问题 的 




















在 百 分 之 九 十 的 情况 下 ， 订 阅 risky() 都 会 导致 RuntimeException。 如 果 进 入 OK 分支， 那 
么 样 例 将 会 注入 零 到 两 秒 的 人 为 延迟 。 以 下 使 用 这 个 有 风险 的 操作 来 阐述 retry()。 
risky() 

.timeout(1, SECONDS) 

.doOnError(th -> log.warn("Will retry", th)) 


.retry() 
.Subscribe(log::info); 


需要 记 住 ， 缓慢 的 系统 其 实 和 有 问题 的 系统 没什么 区 别 ， 但 是 前 者 往往 更 糟糕 ， 因 为 我 们 
将 会 经 历 额 外 的 延迟 。 在 拥有 超时 功能 之 后 ， 有 时 甚至 需要 带 有 重 试 机 制 的 主动 超时 一 一 
当然 ， 重 试 不 能 有 副作用 而 且 操作 是 老 等 的 。retry() 的 行为 方式 非常 简单 : 它 会 将 所 有 
的 事件 和 完成 通知 推送 至 下 游 ， 但 是 不 包含 onError()。 错 误 通知 被 吞噬 了 (所 以 也 不 会 
有 异常 记录 )， 因 此 我 们 需要 使 用 doonError() 回调 (参见 7.4.1 节 )。 每 当 retry() 遇 到 模 
拟 的 RuntimeException 或 TimeoutException 时 ， 它 就 会 尝试 重新 订 呵 。 


警告 一 下 : 如 果 0bservable 进行 了 缓存 ， 或 者 以 某 种 方式 保证 始终 返回 相同 的 元 素 序 列 ， 
那么 retry() 无 法 正常 运行 。 

risky().cached().retry() // 有 问题 的 
如 果 risky() 发 布 了 一 次 错误 ， 那 么 它 将 会 持续 发 布 错误 ， 无 论 你 重新 订阅 多 少 次 均 如 此 。 
为 了 解决 这 个 问题 ， 我 们 可 以 通过 defer() 进一步 延迟 0bservable 的 创建 。 

Observable 


.defer(() -> risky()) 
.retry() 


即便 从 risky() 返回 的 Observable 得 到 缓存 ，defer() 也 会 多 次 调用 risky()。 这 样 ， 我 们 
每 次 可 能 会 得 到 一 个 新 的 Observable。 

通过 延迟 和 限制 尝试 进行 重 试 

简单 的 retry() 方法 非常 有 用 ， 但 是 没有 节 流 或 者 不 限制 尝试 次 数 的 盲目 重 订阅 是 非常 危 
险 的 。 这 样 ，CPU 或 网 络 很 快 就 会 饱和 ， 造 成 大 量 的 负载 。 基 本 上 ， 无 参 的 retry() 就 像 
while 循环 包含 了 一 个 try 语句 ， 而 后 面 的 catch 语句 是 空 的 。 首 先 ， 样 例 应 该 限制 尝试 
次 数 ， 该 功能 恰好 就 是 内 置 的 。 

risky() 


.timeout(1, SECONDS) 
.retry(10) 


retry() 的 整 型 参数 指定 了 要 重新 订阅 的 次 数 ， 因 此 retry(9) 等 价 于 根本 不 进行 重 试 。 
如 果 上 游 的 Observable 失败 了 10 次， 那么 最 后 的 异常 将 会 传递 至 下 游 。 更 灵 话 版 本 的 
retry() 允许 根据 尝试 次 数 和 实际 的 异常 ， 自 行 判断 如 何 进 行 重 试 。 
risky() 
.timeout(1, SECONDS) 


.retry((attempt, e) -> 
attempt <= 10 && !(e instanceof TimeoutException)) 
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这 个 版 本 不 仅 将 重新 订阅 的 次 数 限制 为 10， 还 会 在 出 现 TimeoutException 异常 时 ， 永 和 久 放 
如 果 失 败 是 暂时 的 ， 在 尝试 重新 订阅 之 前 等 待 一 会 儿 是 不 错 的 办 法 。retry() 操作 符 并 没 
有 提供 这 种 开 箱 即 用 的 功能 ， 但 是 它 相 对 容易 实现 。retry() 有 一 个 更 健壮 的 版 本 ， 即 
retryWhen()。 它 接收 一 个 函数 ， 这 个 函数 能 够 处 理由 失败 组 成 的 0bservable。 每 次 上 游 失 
败 ， 这 个 0bservable 就 会 发 布 一 个 Throwable。 如 下 的 代码 片段 想 要 在 重 试 ( 这 是 它 得 名 
的 原因 ) 时 转换 0bservable， 使 其 能 够 发 布 一 个 任意 的 事件 。 

risky() 


.timeout(1, SECONDS) 
.retryWhen(failures -> failures.delay(1, SECONDS)) 


这 个 retryWhen() 样 例 接收 了 一 个 0bservable， 后 者 会 在 上 游 失 败 时 ， 发 布 一 个 Throwable。 
样 例 只 是 简单 地 延迟 了 1 秒 ， 所 以 它 会 在 1 秒 之 后 出 现在 最 终 的 流 中 。 此 时 ， 应 该 使 用 
retryWhen() 进行 重 试 。 如 果 只 是 返回 相同 的 流 (retryWhen(x -> x))，retryWhen() 的 行 
为 将 和 retry() 完全 一 样 ， 也 就 是 在 出 现 错误 时 立即 重新 订阅 。 借 助 retryWhen()， 我 们 还 
可 以 很 容易 地 模拟 retry(10) (几乎 是 相同 的 ， 请 继续 阅读 ) 。 


.retryWhen(failures -> failures.take(10)) 


每 次 失败 发 生 时 ， 我 们 就 会 接收 到 一 个 事件 。 这 里 返回 的 流 会 在 我 们 想 要 进行 重 试 的 时 
候 ， 发 布 任意 一 个 事件 。 因 此 ， 样 例 只 转发 前 10 个 失败 事件 ， 这 样 每 次 失败 后 都 会 立即 
重 试 。 但 是 ，failures 0bservable 出 现 第 11 个 失败 时 会 怎样 呢 ?” 这 就 是 比较 麻烦 的 地 方 
了 。 在 第 10 次 失败 之 后 ，take(19) 操作 符 将 会 立即 发 布 一 个 onComplete 事件 。 因 此 , 在 
第 10 次 重 试 之 后 ，retryWhen() 会 接收 到 一 个 完成 事件 。 这 个 事件 会 被 解读 为 停止 重 试 的 
信号 ， 让 下 游 进入 完成 状态 。 这 意味 着 ， 在 失败 重 试 10 次 之 后 ， 样 例 将 不 再 发 布 任何 内 
容 并 进入 完成 状态 。 但 是 ， 如 果 retryWhen() 返回 的 0bservable 出 现 错误 ， 那 么 这 个 错误 
将 会 被 传递 至 下 游 。 

换 名 话说 ， 只 要 retryWhen() 中 的 observabte 发 布 事件 ， 它 们 就 会 被 解读 为 重 试 请 求 。 但 
是 ， 如 果 发 布 完 成 或 错误 通知 ， 那 么 样 例 将 放弃 重 试 ， 完 成 或 错误 通知 会 被 传递 至 下 游 。 
failures.take(19) 会 重 试 10 次 ， 在 此 之 后 如 果 出 现 了 其 他 失败 ， 样 例 不 会 传递 最 后 的 错 
误 ， 而 是 将 这 个 流 成 功 完成 。 如 下 所 示 。 


static final int ATTEMPTS = 11; 






















































































ee 


.retryWhen(failures -> failures 
.ZipWith(Observable.range(1, ATTEMPTS), (err, attempt) -> 
attempt < ATTEMPTS ? 
Observable.timer(1, SECONDS) : 
Observable.error(err)) 
.flatMap(x -> x) 
) 


这 看 上 去 相当 复杂 ， 但 是 它 的 功能 非常 强大 。 样 例 将 失败 和 从 1 到 11 的 序列 通过 zip 压 
缩 在 一 起 。 我 们 最 多 只 想 执行 10 次 重 试 ， 所 以 如 有 果 重 试 序列 的 值 小 于 11， 样 例会 返回 
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timer(1， SECONDS)。Fretrywhen() 操作 符 会 捕获 这 个 事件 ， 并 在 失败 发 生 的 1 秒 之 后 进行 
重 试 。 但 是 ， 当 第 10 次 重 试 出 现 失败 的 时 候 ， 样 例会 返回 包含 该 错误 的 Observable， 以 
最 后 一 个 看 到 的 异常 完成 该 重 试 机 制 。 
这 提供 了 很 大 的 灵活 性 。 我 们 可 以 在 出 现 特定 异 稼 或 者 认为 重 试 次 数 过 多 时 ， 停 止 进行 重 
试 。 另 外 ， 还 可 以 调整 多 次 尝试 之 间 的 延迟 时 间 。 例 如 ， 第 一 次 重 试 可 以 立即 进行 ， 后 续 
的 重 试 间隔 则 呈 指 数 级 增加 。 
.retryWhen(failures -> failures 
.ZipWith(Observable.range(1, ATTEMPTS), 
this: :handleRetryAttempt) 


.flatMap(x -> x) 
) 


11... 





























Observable<Long> handleRetryAttempt(Throwable err, int attempt) { 
switch (attempt) { 
case 1: 
return Observable.just(42L); 
case ATTEMPTS: 
return Observable.error(err); 
default: 
long expDelay = (long) Math.pow(2, attempt - 2); 
return Observable.timer(expDelay, SECONDS); 
} 
} 


进行 第 一 次 重 试 的 时 候 ， 样 例 返 回 的 0bservable 会 立即 发 布 一 个 任意 的 事件 ， 所 以 重 试 会 
立即 执行 。 在 这 里 ， 返 回 的 事件 的 类 型 和 值 并 不 重要 (只 有 发 布 时 机 真正 有 用 )， 所 以 42 
可 以 替换 成 任意 其 他 的 值 。 最 后 一 次 重 试 时 ， 样 例 向 下 游 Subscriber 转发 一 个 异常 ， 包 含 
了 最 后 失败 的 原因 。 对 于 第 2 次 到 第 10 次 的 重 试 ， 我 们 使 用 如 下 的 指数 公式 进行 计算 。 






































0 if attempt =1 
delay(attemp!t) = 
22e2 if attempt{2,3,4,.…,10} 


7.2 ”测试 和 调试 


流 组 合 可 能 会 非常 困难 ， 尤 其 是 涉及 时 间 的 时 候 。 比 较 令 人 开心 的 是 ，RxJava 对 单元 测试 
提供 了 良好 的 支持 。 使 用 TestSubscriber 可 以 断言 已 发 布 的 事件 ， 但 更 重要 的 是 ，RxJava 
有 一 个 虚拟 时 间 (virtual time) 的 概念 。 本 质 上 ， 我 们 能 够 控制 时 间 的 流逝 ， 所 以 依赖 于 
时 间 的 测试 既 快 捷 又 可 预测 。 


7.2.1 虚拟 时 间 


在 处 理 的 所 有 应 用 程序 中 ， 时 间 都 是 一 个 重要 的 因素 ， 这 里 讨论 的 并 不 是 延迟 和 响应 时 
间 。 所 有 事情 的 发 生 都 有 一 个 时 间 点 ， 事 件 发 生 的 顺序 非常 重要 ， 而 任务 会 调度 到 未 来 
执行 。 因 此 ， 我 们 需要 花费 大 量 时 间 寻 找 只 在 特定 日 期 或 时 区 出 现 的 bug。 在 测试 时 间 相 



















































































测试 和 排 错 | 209 


关 的 代码 时 ， 并 没有 什么 既成 的 方法 。 有 一 种 实践 叫 作 基于 属性 的 测试 (property-based 
testing)， 它 的 目标 是 生成 数 百 个 测试 用 例 (有 了 时 是 随机 的 )， 以 便于 测试 范围 广泛 的 用 户 
参数 。 例 如 ， 验 证 一 个 简单 的 属性 ， 对 于 任何 给 定 的 日 期 ， 先 增加 后 减少 一 个 月 将 返回 相 
同 的 日 期 ， 如 下 所 示 。 


import spock.Lang.Specification 
import spock.lang.Unroll 














import java.time.LocalDate 
import java.time.Month 


class PlusMinusMonthSpec extends Specification { 


static final LocalDate START_DATE = 
LocalDate.of(2016, Month.JANUARY, 1) 


@Unroll 
def '#date +/- 1 month gives back the same date'() { 
expect: 
date == date.plusMonths(1).minusMonths(1) 
where: 


date << (0..365).collect { 
day -> START_DATE.plusDays(day) 
} 


} 


使 用 Groovy 语言 的 Spock 框架 快速 生成 366 个 不 同 的 测试 用 例 。expect 块 中 的 代码 会 针 
对 where 代码 块 生成 的 每 个 值 都 执行 一 遍 。 在 where 代码 块 中 ， 我 们 迄 代 从 9 到 365 的 整 
数值 ， 从 而 生成 2016-01-91 到 2016-12-31 的 所 有 日 期 。 断 言 非常 简单 直接 : 如 果 将 任意 
的 日 期 增加 一 个 月 再 减少 一 个 月 ， 那 么 我 们 能 够 再 次 得 到 之 前 的 日 期 。 不 过 ， 在 366 个 测 
试用 例 中 有 6 个 是 失败 的 。 

date == date.pLusMonths(1) .mtnusMonths(1) 


| | :| | 
| | | 2016-02-29 2016-01-29 
| | 2016-01-30 





























date == date.plusMonths(1).minusMonths(1) 


| | | 
| | | 2016-02-29 2016-01-29 
| | 2016-01-31 


date == date.plusMonths(1).minusMonths(1) 


| [| | 
| | | 2016-04-30 2016-03-30 





| | 2016-03-31 
| false 
2016-03-31 


相信 你 能 够 计算 出 其 他 测试 失败 的 日 期 。 这 个 有 点 牵强 的 样 例 是 为 了 展现 时 域 (time 
domain) 的 复杂 性 。 但 是 ， 日 历 的 特殊 性 并 不 是 我 们 在 计算 机 系统 中 处 理 时 间 时 感到 头 
疼 的 根源 。RxJava 通过 尽 可 能 地 避免 使 用 状态 和 采用 纯 函数 ， 来 解决 并 发 的 复杂 性 。 这 
里 的 “ 纯 ” 指 函数 (或 操作 符 ) 应 该 显 式 声明 所 有 的 输入 和 输出 。 这 使 得 测试 更 加 容 
易 。 但 是 ， 对 时 间 的 依赖 基本 上 都 是 隐形 的 。 每 次 看 到 new Date()、Instant.now()、 
System.currentTimeMillis() 等 ， 我 们 就 会 对 随时 间 变 化 的 外 部 值 产生 依赖 。 依 赖 单 例 
是 不 好 的 设计 ， 从 测试 的 角度 更 是 如 此 。 但 是 ， 读 取 当 前 时 间 实 际 上 依赖 于 到 处 皆 可 访问 
的 系统 级 单 例 。 

为 了 突显 对 时 间 的 依赖 ， 有 种 模式 是 使 用 一 个 伪造 的 系统 时 钟 。 这 对 所 有 开发 人 员 的 要 求 
都 非常 严格 ， 要 将 时 间 相 关 的 代码 代理 给 一 个 可 以 仿造 的 特定 服务 。Java 8 通过 引入 Clock 
抽象 规范 了 这 种 方法 ， 大 致 如 下 所 示 。 


public abstract class Clock { 

















public static Clock system(ZoneId zone) { /* ... */} 


public long millis() { 
return instant().toEpochMilli(); 


} 


public abstract Instant instant(); 


} 


有 意思 的 是 ，RxJava 有 一 种 类 似 的 抽象 ， 本 书 已 经 非常 详细 地 介绍 过 了 : Scheduler ( 参 
见 4.9.1 节 )。 你 可 能 会 问 ，Scheduter 与 时 间 的 流逝 又 有 什么 关系 呢 ? 因为 RxJava 中 的 所 
有 事情 要 么 立即 发 生 ， 要 么 安排 在 未 来 某 个 时 间 发 生 。 在 RxJava 中 ， 正 是 Scheduler 完全 
控制 每 行 代码 何 时 执行 。 


7.2.2 单元 测 试 中 的 调度 器 
各 种 Scheduler (比如 io() 或 computation()) 的 功能 就 是 在 特定 的 时 间 点 运行 任务 。 但 
是 ， 有 一 个 特殊 的 test() Scheduler， 它 有 两 个 非常 有 趣 的 方法 : advanceTimeBy() 和 
advanceTimeTo()。TestScheduler 的 两 个 方法 能 够 手动 向 前 推进 时 间 ， 否 则 ， 时 间 会 被 永 
远 冻 结 。 这 意味 着 ， 在 手动 向 前 推动 时 间 (可 以 在 任何 觉得 有 用 的 时 间 点 ) 之 前 ， 这 个 
Scheduler 不 会 调度 执行 任何 未 来 的 任务 。 
以 下 样 例 是 随 着 时 间 推 移出 现 的 事件 序列 。 
TestScheduler sched = Schedulers.test(); 


Observable<String> fast = Observable 
.interval(10, MILLISECONDS, sched) 
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.map(x -> "F" + X) 
.take(3); 

Observable<String> slow = Observable 
.interval(50, MILLISECONDS, sched) 
.map(x -> "S" + X); 


Observable<String> stream = Observable.concat(fast, slow); 
stream.subscribe(System.out: :println); 
System.out.println("Subscribed"); 


在 订阅 之 时 ， 应 该 很 快 就 会 看 到 三 个 事件 F6、F1 和 F2， 每 个 事件 的 延迟 是 10 毫秒 ， 随 
后 是 无 限 数量 的 事件 S9、S1...， 每 个 事件 间隔 50 毫秒 。 我 们 该 如 何 测 试 这些 流 已 经 成 
功 合并 到 一 起 ， 这 些 事件 会 按照 正确 的 顺序 在 正确 的 时 间 出 现 ? 这 里 的 关键 在 于 显 式 传递 
使 用 TestScheduler。 











TimeUnit.SECONDS. sleep(1); 
System.out.println("After one second"); 
sched.advanceTimeBy(25, MILLISECONDS); 


TimeUnit.SECONDS. sleep(1); 
System.out.println("After one more second"); 
sched.advanceTimeBy(75, MILLISECONDS); 


TimeUnit.SECONDS. sleep(1); 
System.out.println("...and one more"); 
sched.advanceTimeTo(200, MILLISECONDS); 


程序 的 输出 是 可 预测 和 可 重复 的 ， 完 全 独立 于 系统 时 间 、 瞬 间 流 量 峰值 、GC 暂停 等 。 


Subscribed 

After one second 

FO 

F1 

After one more second 





.. .and one more 
S2 

下 文 描述 了 程序 执行 的 过 程 。 

(1) 订 阅 stream 0bservable 之 后 ， 它 会 调度 未 来 10 毫秒 后 的 F9 任务 。 但 是 ， 这 里 使 用 了 
TestScheduler ， 它 会 处 于 绝对 的 空 闪 状态 ， 除 非 手 动向 前 推进 时 间 。 

人) 休 眼 1 秒 其 实 无 关 紧 要 ， 甚 至 可 以 省 略 ，TestSschedutLer 独立 于 系统 时 间 ， 因 此 根本 不 
会 有 事件 发 布 出 来 。 这 里 的 休 眼 只 是 为 了 证 明 TestScheduler 能 够 正常 运行 。 如 果 这 里 
不 是 TestScheduler ， 而 是 普通 的 (默认 的 ) 调度 器 ， 我 们 可 以 预期 在 控制 台中 已 经 出 
现 了 多 个 事件 。 

(3) 调用 advanceTimeBy(25ms) 会 强制 时 间 向 前 推进 至 第 25 这 秒 ， 调 度 的 任务 会 被 触发 或 执 
行 。 这 会 导致 事件 F6 (第 10 毫秒) 和 F1 (第 20 毫秒 ) 出 现在 控制 台中 。 



































(4) 接 下 来 休眠 的 1 秒 内 不 会 有 任何 输出 ，TestSscheduter 会 忽略 真正 的 时 间 。 但 是 ， 调 用 
advanceTimeBy(75ms) (所 以 现在 的 逻辑 时 间 是 第 100 毫秒 ) 会 进一步 触发 F2 (第 30 毫 
秒 ) 和 se (第 80 毫秒 ) 事件 。 除 此 之 外 ， 不 会 发 生 其 他 事件 。 

(5) 在 真实 时 间 又 消耗 1 秒 之 后 ， 将 时 间 的 绝对 值 推进 至 200 毫秒 (advanceTimeTo 
(200ms)， 而 advanceTimeBy() 使 用 的 是 相对 时 间 )。TestScheduler 实现 了 此 时 触发 S1 
(第 130 毫秒 ) 和 5S2 (第 180 毫秒 )。 但 是 除 此 之 外 不 会 触发 其 他 事件 ， 即 便 永远 等 待 
下 去 也 是 如 此 。 


可 以 看 到 ，TestScheduter 比 普通 的 仿造 Clock 抽象 更 加 智能 。 不 仅 能 够 完全 控制 当前 时 
间 ， 还 能 任意 推迟 所 有 事件 。 需 要 注意 的 是 ， 基 本 上 要 将 TestScheduter 传递 给 每 个 接收 
可 选 Scheduler 参数 的 操作 符 。 为 了 简便 ， 这 些 操 作 符 会 使 用 一 个 默认 的 computation() 
Scheduler。 但 是 从 可 测试 性 的 角度 ， 样 例 应 该 优先 传递 显 式 的 Scheduler。 另 外 ， 可 以 考 
虑 依赖 注入 的 方式 ， 在 外 部 提供 Scheduler。 


但 是 ， 只 有 TestScheduler 还 不 够 。 它 在 单元 测试 中 非常 有 用 ， 单 元 测试 的 可 预测 性 是 必 
的 ， 偶 尔 出 现 的 测试 失败 会 令 人 非常 诅 形 。 第 8 章 将 介绍 支持 异步 bbservable 单元 测试 
的 工具 和 技术 。 


7.3 单元 测试 


长 期 以 来 ， 编 写 可 测试 的 代码 并 拥有 一 套 稳定 的 测试 集 都 是 必 备 的 ， 并 不 是 什么 新 颖 的 方 
式 。 无 论 以 测试 驱动 开发 (Test-Driven Development，TDD) 精神 优先 编写 测试 ， 还 是 随 
后 通过 集成 测试 验证 假设 ， 我 们 都 应 该 非常 熟悉 自动 化 测试 了 。 因 此， 使 用 的 工具 ( 框 
架 、 库 、 平 台 ) 必须 支持 自动 化 测试 ， 这 种 能 力 是 在 进行 技术 决策 时 应 该 考虑 的 一 个 方 
面 。 不 用 担心 ， 尽 管 异 步 、 事 件 驱 动 架构 领域 非常 复杂 ， 但 是 RxJava 为 单元 测试 提供 了 
良好 的 支持 。 时 间 方 面 的 确定 性 ， 再 加 上 对 纯 函 数 和 函数 组 合 (良好 的 函数 式 编程 基础 ) 
的 关注 能 够 极 大 地 提升 测试 体验 。 


校 验 已 发 布 的 事件 


首先 ， 需 要 定义 测试 Observable 的 目标 。 如 果 方 法 返回 Observable， 我 们 可 能 需要 确保 如 
下 事项 。 


。 事件 按照 正确 的 顺序 发 布 。 

。 错误 得 到 恰当 地 传递 。 

。 各 种 操作 符 的 组 合 符合 预期 。 

。 事件 在 恰当 的 时 间 出 现 。 
支持 回 压 。 

除 此 之 外 ， 还 有 很 多 要 求 。 上 述 前 两 项 要 求 很 简单 ， 并 不 需要 RxJava 的 特殊 支持 。 基 本 

上 将 发 布 的 所 有 内 容 收集 起 来 ， 然 后 使 用 我 们 喜欢 的 库 执行 断言 即 可 。 


import org.junit.Test; 
import static org.assertj.core.api.Assertions.assertThat; 
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QTest 
public void shouldApplyConcatMapInOrder() throws Exception { 
List<String> list = Observable 
.range(1, 3) 
.concatMap(x -> Observable.just(x, -x)) 
.map(Object: :toString) 
.toList() 
.toBLocking() 
.SingLe(); 


assertThat(list).containsExactly("1", "-1", "2", "-2", "3", "-3"); 


} 


上 述 简 单 测试 案例 通过 熟知 的 toList() 一 toBlocking() 一 single() 构造 ， 将 0bservable 
<Integer> 转换 成 了 List<Integer> (参见 42 节 )。 正 常情 况 下 ，0bservable 都 是 异 
步 的 ， 为 了 具备 可 预测 性 并 实现 快捷 的 测试 ， 样 例 必须 要 执行 这 样 的 转换 。 在 使 用 
BlockingObservable 的 时 候 ， 样 例 也 可 以 很 容易 地 断言 onError() 通知 。 异 常会 在 订阅 时 
重新 简单 地 抛 出 。 广 意 ， 检 查 型 异常 会 使 用 RuntimeException 进行 包装 一 一 只 有 好 的 测试 
才能 证 明 这 一 切 。 


如 
操 





























import com.google.common.io.Files; 
import static java.nio.charset.StandardCharsets.UTF_8; 
import static org.assertj.core.api.Assertions.failBecauseExceptionWasNotThrown; 


File file = new File("404.txt"); 

BlockingObservable<String> fileContents = Observable 
.fromCallable(() -> Files.toString(file, UTF_8)) 
.toBlocking(); 


try { 
fileContents.single(); 
failBecauseExceptionWasNotThrown(FileNotFoundException.class); 
} catch (RuntimeException expected) { 
assertThat(expected) 
.hasCauseInstanceOf(FileNotFoundException.class); 


} 














一 、 


果 想 要 以 延迟 执行 的 方式 创建 最 多 只 发 布 一 个 元 素 的 Observable， 那 么 fromCallable() 




















FE 符 是 非常 便利 的 。 它 还 会 进行 错误 处 理 和 回 压 ， 所 以 对 于 单元 素 的 流 ， 应 该 优先 使 用 











它 ， 而 不 是 0bservable.create()。 使 用 其 他 类 型 的 单元 测试 可 以 判断 我 们 对 各 种 操作 符 及 

















其 行为 的 理解 是 否 正确 。 例 如 ，concatMapDelayError() 到 底 是 做 什么 的 ? 你 可 以 逐一 进行 





尝试 ,但 是 拥有 一 个 人 人 都 能 阅读 和 快速 理解 的 自动 化 测试 ， 会 带 来 巨大 的 优势 。 





import static rx.Observable.fromCallable; 


Observable<Notification<Integer>> notifications = Observable 
.just(3, 0, 2, 0, 1, 0) 
.CconcatMapDelayError(x -> fromCallable(() -> 100 / x)) 
.materialize(); 





List<Notification.Kind> kinds = notifications 
.map(Notification: :getKind) 
.toList() 
.toBlocking() 
.Single(); 


assertThat(kinds).containsExactly(OnNext, OnNext, OnNext, OnError); 


如 果 使 用 标准 的 concatMap()， 第 二 个 元 素 (9) 的 转换 会 失败 并 终结 整个 流 。 但 是 ， 我 们 
清晰 地 看 到 最 终 的 流 有 4 个 元 素 : 三 个 onNext， 随 后 是 onError。 可 以 使 用 另外 一 个 断言 
判断 最 终 的 值 将 是 33 (100/3)、50 和 100。 这 很 好 地 阐述 了 concatMapDelayError() 是 如 
何 运行 的 ， 如 果 转 换 过 程 中 出 现 了 错误 ， 错 误 不 会 向 下 游 传递 ， 而 操作 符 会 继续 执行 。 只 
有 上 游 源 完 成 的 时 候 ， 才 会 传递 一 个 onError 通知 ， 表 明 在 这 个 过 程 中 遇 到 的 错误 。 最 后 
的 这 个 测试 用 例 已 经 无 法 将 0bservable 转换 成 List 了 ， 因 为 它 会 立即 抛 出 一 个 错误 。 在 
这 种 情况 下 ，materialize() 就 非常 有 用 了 : 每 种 类 型 的 事件 (onNext、onCompleted 和 
onError) 都 会 使 用 一 个 通用 的 Notification 对 象 进行 包装 ， 随 后 检查 这 些 对 象 。 但 是 这 
种 方式 非常 烦琐 ， 代 码 也 难以 阅读 。 这 时 使 用 TestSubscriber 就 非常 便利 了 ， 如 下 所 示 。 
Observable<Integer> obs = Observable 


.just(3, 0, 2, 0, 1, 0) 
.ConcatMapDelayError(x -> Observable.fromCallable(() -> 100 / x)); 





















































TestSubscriber<Integer> ts = new TestSubscriber<>(); 
obs.subscribe(ts); 


ts.assertValues(33, 50, 100); 
ts.assertError(ArithmeticException.class); // 失 败 


TestSubscriber 类 非常 简单 : 它 会 在 内 部 存储 所 有 接收 到 的 事件 。 这 样 ， 我 们 随后 可 
以 进行 查询 。Testsubscriber 还 提供 了 一 组 断言 ， 在 测试 场景 下 它们 非常 有 用 。 我 们 
需要 做 的 就 是 创建 一 个 Testsubscriber， 订 阅 要 测试 的 0bservable 并 检查 它 的 内 容 。 
奇怪 的 是 ， 上 述 测 试 会 失败 。assertError() 失败 的 原因 在 于 预期 流 完成 时 将 会 出 现 
ArithmeticException， 但 实际 得 到 的 是 CompositeException。 后 者 将 这 个 过 程 中 过 到 的 三 
个 ArithmeticException 都 聚合 了 起 来 。 这 也 从 另 一 个 方面 说 明了 ， 通 过 实际 运行 操作 符 
和 执行 自动 化 测试 来 学 习 操 作 符 是 非常 有 用 的 。 

将 Testsubscriber 和 Testscheduter 组 合 使 用 时 尤为 高 效 。 一 个 典型 的 场景 是 在 向 前 推进 
时 间 的 同时 插入 断言 ， 以 观察 事件 如 何 随时 间 的 推移 而 流动 。 假 设 有 一 个 返回 0bservable 
的 服务 ， 如 下 所 示 ， 它 的 实现 细节 无 关 紧 要 。 

interface MyService { 


Observable<LocalDate> externalCall(); 


} 
这 里 不 会 将 各 种 关注 项 混合 在 一 起 ， 而 是 决定 围绕 Myservice 构建 一 个 包装 器 。 无 论 底层 
的 Myservice 实现 是 什么 ， 都 能 为 其 添加 超时 功能 。 基 于 你 可 能 已 经 猪 到 的 原因 ， 以 下 代 
码 更 进一步 ， 将 timeout() 操作 符 使 用 的 Scheduler 进行 了 外 部 化 。 
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class MyServiceWithTimeout impLements MyService { 


private final MyService delegate; 
private final Scheduler scheduler; 


MyServiceWithTimeout(MyService d, Scheduler s) { 
this.delegate = d; 
this.scheduler = s; 


} 


@Override 
public Observable<LocalDate> externalCall() { 
return delegate 
.externalCall() 
.timeout(1, TimeUnit.SECONDS, 
Observable.empty(), 
scheduler); 


} 


MyServiceWithTimeout 包装 了 另外 一 个 Myservice 实例 ， 添 加 了 具有 备用 功能 的 1 秒 超时 。 
按照 RxJava 的 理念 ， 每 个 类 都 有 一 个 可 组 合 的 功能 ， 就 像 操 作 符 非常 集中 又 易于 组 合 。 
假设 我 们 想 要 测试 超时 功能 能 否 真正 发 挥 作用 ， 单 元 测试 应 该 极其 快捷 。7.2.1 节 的 开篇 介 
绍 了 PlusMinusMonthspec， 为 21 世纪 的 每 一 天 (超过 36 000 个 测试 用 例 ) 调用 一 遍 该 测 
试 大 约 需 要 1 秒 。 一 个 好 的 单元 测试 ， 执 行 时 间 不 应 该 超过 几 毫 秒 。 


1 秒 的 超时 似乎 并 不 是 太 长 ， 但 是 如 果 有 上 百 个 这 样 的 场景 ， 那 么 就 会 消耗 相当 长 时 间 了 。 
我 们 可 以 将 这 个 超时 时 间 外 部 化 (无 论 如 何 都 是 一 种 好 的 做 法 )， 并 在 单元 测试 中 缩短 它 
的 值 ， 比 如 变 成 100 毫秒 。 在 这 样 的 情况 下 ， 样 例 可 以 休眠 90 毫秒 ， 并 断言 超时 机 制 没 
有 发 挥 作 用 ， 然 后 再 休眠 20 秒 ， 校 验 超 时 机 制 是 否 返 回 了 一 个 空 的 0bservable。 邻 人 遗 
憾 的 是 ， 这 种 方式 非常 脆弱 ， 可 能 会 受到 上 下 文 切 换 、 垃 圾 收集 和 暂停、 系统 负载 变化 等 因 
素 的 影响 。 简 而 言 之 ， 测 试 可 以 相对 稳定 ， 也 可 以 相对 快捷 。 但 是 ， 它 越 快 ， 出 现 误 报 失 
败 的 频率 就 越 高 。 不 稳定 的 测试 比 根 本 没有 测试 更 糟糕 ， 因 为 这 邻 人 感到 祖 形 ， 你 无 法 信 
任 它们 ， 并 最 终 将 其 移 除 。 

RxJava 提供 了 一 种 人 为 的 、 可 探 的 时 钟 ， 它 是 完全 可 预测 的 。 通 过 手动 向 前 推进 时 
间 ， 我 们 能 够 实现 百分之百 的 精确 性 ， 同 时 又 能 实现 测试 的 快捷 执行 。 首 先 ， 仿 造 一 个 
MyService (通过 Mockito) ， 它 能 返回 任意 的 0bservable。 










































































import static org.mockito.BDDMockito.given; 
import static org.mockito.Mockito.mock; 


private MyServiceWithTimeout mockReturning( 
Observable<LocalDate> result, 
TestScheduler testScheduler) { 
MyService mock = mock(MyService.class); 
given(mock.externalCall()).willReturn(result); 
return new MyServiceWithTimeout(mock, testScheduler); 


} 
现在 ,编写 两 个 单元 测试 。 第 一 个 测试 能 够 确保 ， 如 果 externalCall() 永远 不 结束 ， 样 例 
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在 1 秒 之 后 会 遇 到 超时 。 


QTest 
public void timeoutWhenServiceNeverCompletes() throws Exception { 
//given 
TestScheduler testScheduler = Schedulers.test(); 
MyService mock = mockReturning( 
Observable.never(), testScheduler); 
TestSubscriber<LocalDate> ts = new TestSubscriber<>(); 





//when 
mock.externalCall().subscribe(ts); 


//then 

testScheduler .advanceTimeBy(950, MILLISECONDS); 
ts.assertNoTerminalEvent(); 

testScheduler .advanceTimeBy(100, MILLISECONDS); 
ts.assertCompleted(); 

ts.assertNoValues(); 


} 





never() 操作 符 返 回 的 0bservable 永远 不 会 完成 ， 并 且 不 会 发 布 任何 值 。 这 模拟 了 MyService 





调用 非常 缓慢 的 场景 。 然 后 ， 进 行 两 个 断言 的 序列 。 首 先 ， 将 时 间 向 前 推移 至 超时 净值 











I 





(950 毫秒 ) 之 前 ， 并 确保 Testsubscriber 没有 完成 或 失败 。 在 100 毫秒 〈 超 时 间 值 ) 之 
后 ， 样 例 断 言 流 已 经 完成 (assertCompLeted())， 并 且 没 有 任何 值 (assertNoValues())。 





我 们 也 可 以 使 用 assertError()。 
第 二 个 测试 要 确保 在 达到 配置 的 羡 值 之 前 ， 超 时 机 制 不 会 发 挥 作用 。 


QTest 
public void valueIsReturnedJustBeforeTimeout() throws Exception { 
//given 
TestScheduler testScheduler = Schedulers.test(); 
Observable<LocalDate> slow = Observable 
.timer(950, MILLISECONDS, testScheduler) 
.map(x -> LocalDate.now()); 
MyService myService = mockReturning(slow, testScheduler); 
TestSubscriber<LocalDate> ts = new TestSubscriber<>(); 


//when 
myService.externalCall().subscribe(ts); 


//then 

testScheduler .advanceTimeBy(930, MILLISECONDS); 
ts.assertNotCompleted(); 

ts.assertNoValues(); 

testScheduler .advanceTimeBy(50, MILLISECONDS); 
ts.assertCompleted(); 

ts.assertValueCount(1); 


} 








advanceTimeBy() 在 测试 中 相当 于 休眠 ， 它 会 等 待 一 些 操作 执行 ， 但 是 并 没有 真正 地 休 
眼 。 你 可 以 测试 各 种 类 型 的 操作 符 ， 比 如 buffer()、sample() 等 ， 只 要 精心 传递 自 定义 
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的 Scheduler 即 可 。 谈 到 调度 器 ， 我 们 很 容易 使 用 Schedulers.immediate() (参见 4.9.1 
节 )， 而 不 是 标准 的 调度 器 。 但 是 ， 这 个 Scheduler 不 支持 同步 ， 它 会 在 调用 者 线程 的 
上 下 文中 执行 各 种 操作 。 这 种 方式 在 某 些 场景 下 能 够 正常 运行 ， 但 是 一 般 应 该 优先 使 用 
TestScheduLer， 它 的 用 例 更 广泛 。 

遵循 依赖 注入 原则 是 非常 重要 的 。 否 则 ， 我 们 就 无 法 将 各 种 Scheduler 与 TestSchedutLer 
进行 替换 了 。 在 这 方面 ， 有 些 技术 可 以 提供 帮助 ， 比 如 RxJavaSchedulersHook 插件 (plug- 
in) 。RxJava 有 一 组 插件 , 它们 能 够 全 局 地 改变 库 的 行为 。 举 例 来 说 , RxJavaScheduLersHook 
能 够 将 标准 的 computation() Scheduler (或 其 他 调度 器 ) 替换 为 测试 调度 器 ， 如 下 所 示 。 


private final TestScheduler testScheduler = new TestScheduler(); 
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@Before 
public void alwaysUseTestScheduler() { 
RxJavaPlugins 
.getInstance() 
.registerSchedulersHook(new RxJavaSchedulersHook() { 
@Override 
public Scheduler getComputationScheduler() { 
return testScheduler; 


} 


@Override 
public Scheduler getIOScheduler() { 
return testScheduler; 


} 


@Override 
public Scheduler getNewThreadScheduler() { 
return testScheduler; 
} 
]); 
} 


这 种 全 局 的 方式 有 很 多 局 限 性 。 在 整个 JVM 中 ， 我 们 只 能 注册 RxJavaSchedulersHook 一 
次 ， 所 以 第 二 次 调用 这 个 @Before 方法 将 会 失败 。 你 可 以 进行 处 理 ， 但 是 这 会 变 得 更 加 
复杂 。 同 时 ， 并 行 运行 单元 测试 (通常 情况 下 ， 单 元 测试 之 间 是 独立 的 ， 所 以 这 并 不 是 
什么 问题 ) 也 不 可 能 实现 。 因 此 ， 控 制 时 间 的 唯一 可 扩展 方案 就 是 尽 可 能 地 显 式 传递 
TestScheduler, 


TestSubscriber 的 最 后 一 个 练习 就 是 测试 回 压 。6.2.4 节 研 究 了 生成 连续 自然 数 的 两 个 无 穷 
Observable 实现 ， 其 中 一 个 使 用 老式 未 经 加 工 的 0Observable.create()， 它 不 支持 回 压 。 


Observable<Long> naturals1() { 
return Observable.create(subscriber -> { 
long i = 0; 
while (!subscriber.isUnsubscribed()) { 
subscriber .onNext(i+t+); 






































以 下 是 更 高 级 且 推荐 的 实现 方式 ， 完 全 支持 回 压 。 


Observable<Long> naturals2() { 
return 0bservabLe.create( 
SyncOnSubscribe.createStatefuL( 
() -> 0L， 
(cur, observer) -> { 
observer .onNext(cur); 
return CUr + 1; 





)); 
} 
从 功能 的 角度 ， 这 两 者 相同 ， 都 是 无 穷 流 ， 但 是 (比如 ) 你 可 以 只 选取 其 中 一 个 子 集 。 不 
过 ， 借 助 TestSubscriber， 可 以 很 容易 地 以 单元 测试 的 方式 校 验 给 定 的 Observable 是 否 支 
持 回 压 。 


TestSubscriber<Long> ts = new TestSubscriber<>(0); 

















naturals1() 
.take(10) 
.Subscribe(ts); 


ts.assertNoValues(); 
ts.requestMore(100); 
ts.assertValueCount(10); 
ts.assertCompleted(); 





这 个 样 例 的 关键 部 分 是 TestSubscriber<>(0)。 如 果 没 有 它 ，TestSsubscriber 只 会 以 源 规 
定 的 速度 接收 所 有 内 容 。 但 是 ， 如 果 在 订阅 之 前 没有 请 求 任何 数据 ， 那 么 TestSubscriber 
也 不 会 从 0bservable 中 请 求 数据 。 这 就 是 尽管 源 0bservable 已 经 发 布 了 10 个 值 ， 
assertNoValues() 依然 能 够 成 功 的 原因 。 随 后 请 求 100 个 条 目 (为 了 安全 起 见 ), 但 是 源 
Observable 只 生成 了 10 个 条 目 ， 这 就 是 它 能 够 生成 的 数量 。 对 于 naturals1 的 测试 几乎 会 
立即 失败 ， 输 出 的 消息 如 下 。 


AssertionError: No onNext events expected yet some received: 10 


原生 的 0bservable 会 在 接收 10 个 事件 后 就 停止 发 布 事件 ， 尽 管 这 个 0bservable 可 能 是 
无 穷 的 。take(10) 操作 符 会 立即 取消 订阅 ， 结 束 内 部 的 while 循环 。 但 是 ，naturals1 忽 
略 了 TestSubscriber 的 回 压 请 求 ， 后 者 会 接收 到 它 没有 请 求 的 条 目 。 如 果 将 源 赫 换 为 
naturals2， 测 试 就 能 够 通过 。 这 也 是 我 们 避免 使 用 0bservable.create()， 而 使 用 内 置 的 
工厂 和 SyncOnSubscribe 的 另 一 个 原因 。 


TestSubscriber 有 很 多 其 他 的 断言 。 其 中 有 一 些 会 阻塞 等 待 完成 ， 比 如 awaitTerminalEvent()。 
但 是 大 多 数 会 断言 订阅 者 当前 的 状态 ， 所 以 你 可 以 随时 间 推 移 观 察 事 件 的 流动 。 


7.4 监控 和 调试 


监控 各 种 流 之 间 的 交互 并 在 出 现 问题 时 进行 排查 解决 ， 在 RxJava 中 是 一 个 非常 困难 的 主 
题 。 实 际 上 ， 相 对 于 阻塞 式 架构 ， 每 种 异步 事件 驱动 架构 在 进行 问题 排查 时 都 更 加 困难 。 
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同步 操作 失败 时 ， 异 常会 在 整个 调用 堆栈 流动 ， 暴 露 导 致癌 题 的 精确 操作 序列 ， 从 HITP 
服务 器 到 所 有 的 过 着 器、 切面 、 业 务 逻 辑 等 。 在 异步 系统 中 ， 调 用 堆栈 的 用 处 很 有 限 ， 
为 事件 跨越 线程 边界 后 ， 就 无 法 获取 原始 的 调用 堆栈 了 。 相 同 的 情况 也 适用 于 分 布 式 系 
统 。 本 市 会 就 如 何在 使 用 RxJava 的 应 用 程序 中 更 容易 地 监控 和 调试 ， 给 出 一 定 的 提示 。 


7.4.1 doon...() 回 调 

每 个 bbservablte 都 有 一 组 回调 方法 ， 你 能 够 使 用 它们 查看 各 种 事件 ， 几 种 方法 如 下 。 
。 doOnCompleted() 

。 doOnEach() 

。 doOnError() 

。 doOnNext() 

。 doOnRequest() 

。 doOnSubscribe() 

。 doOnTerminate() 











。 doonUnsubscribe() 


它们 的 共同 点 就 是 不 允许 以 任何 方式 改变 0bservable 的 状态 。 而 且 它 们 都 返回 同一 个 
0bservabLe， 于 是 ， 这 些 方法 成 为 了 先入 日 志 逻 辑 的 理想 场所 。 例 如 ， 有 些 初 学 者 很 容易 
忘记 ，0bservable.create() 中 的 代码 会 为 每 个 新 的 Subscriber 都 执行 一 壳 。 这 一 点 非常 
重要 ， 当 订阅 引发 像 网 络 调 用 之 类 的 副作用 时 更 是 如 此 。 为 了 检测 这 样 的 问题 ， 最 好 记录 
下 对 重要 源 的 每 次 订阅 。 

Observable<Instant> timestamps = Observable 


.fromCallable(() -> dbQuery()) 
.do0nSubscribe(() -> log.info("subscribe()")); 























timestamps 

.ZipWith(timestamps.skip(1), Duration::between) 

.map(Object: :toString) 

.Subscribe(log::info); 
上 述 程 序 会 查询 数据 库 (dbQuery()) 并 以 0bservable<Instant> 的 形式 检索 一 些 时 序 
数据 。 我 们 想 要 对 这 个 流 进行 一 些 转 换 ， 计 算出 每 组 连续 Instant 之 间 的 持续 时 间 (使 
用 java.time 包 的 Duration 类 ) : 第 一 个 和 第 二 个 之 间 、 第 二 个 和 第 三 个 之 间 ， 以 此 类 
推 。 实 现 该 功能 的 一 种 方式 就 是 使 用 zip() 将 该 流 与 它 本 身 进行 组 合 ， 并 偏 移 一 个 元 素 。 
通过 这 种 方式 ， 将 第 一 个 元 素 和 第 二 个 元 素 连 接 起 来 ， 第 二 个 元 素 和 第 三 个 元 素 连 接 起 
来 ， 直 至 最 后 。 没 有 预料 到 的 是 ，zipWith() 实际 上 会 订阅 所 有 底层 流 ， 这 意味 着 同一 个 
timestamps Observable 订阅 了 两 次 。 这 个 问题 通过 观察 doonSubscribe() 就 可 以 发 现 ， 因 
为 这 个 方法 被 调用 了 两 次 。 这 会 导致 重复 的 数据 库 查 询 ， 这 个 问题 在 第 2 章 已 经 进行 过 详 
细 地 讨论 。 
谈 到 zip()， 借 助 回 压 功能 ， 它 不 再 无 限 缓存 较 快 的 流 ， 等 待 较 慢 的 流 发 布 事件 。 相 
反 ， 它 会 从 每 个 0bservable 中 请 求 固 定数 量 的 一 批 值 。 如 果 它 接收 到 更 多 的 值 ， 将 抛 出 


MissingBackpressureException。 
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.do0nSubscribe(() -> log.info("subscribe()")) 
.doOnRequest(c -> log.info("Requested {}", c)) 
.do0nNext(instant -> log.info("Got: {}", instant)); 
do0nRequest() 会 记录 Requested 128， 这 个 值 是 由 zip 操作 符 选择 的 。 即 便 源 是 无 穷 的 ， 
或 者 事件 的 数量 非常 庞大 ， 如 果 0bservable 对 回 压 支持 良好 ， 随 后 最 多 也 只 能 看 到 128 条 
信息 ， 比 如 Got: .….。doonNext() 是 我 们 可 以 使 用 的 另 一 个 回调 。 还 有 doonError() 也 经 
常会 用 到 ， 每 当 上 游 出 现 错误 通知 ， 就 会 触发 这 个 回调 。 你 不 能 使 用 doonError() 进行 任 
何 错误 处 理 ， 它 只 能 用 来 进行 日 志 记 录 。 这 个 回调 不 会 消费 错误 通知 ， 而 是 将 其 向 下 游 继 
续 传递 。 
Observable<String> obs = Observable 
.<String>error(new RuntimeException("Swallowed")) 
.doOnError(th -> log.warn("onError", th)) 
.OnErrorReturn(th -> "Fallback"); 
onErrorReturn() 看 上 去 非常 整洁 。 它 能 够 很 轻松 地 吞噬 异常 ， 将 异常 奉 换 为 一 个 备用 值 。 
但 是 记录 异常 是 我 们 的 责任 。 为 了 让 函数 更 加 短小 且 可 组 合 ， 样 例 首先 在 doonError() 中 
记录 异常 ， 然 后 在 下 一 行 代码 中 进行 无 声 地 处 理 ， 这 种 方式 会 更 健壮 一 些 。 不 对 异常 进行 
日 志 记 录 可 不 是 什么 好 主意 ， 我 们 必须 要 仔细 决策 ， 不 可 下 忽 。 


其 他 的 操作 符 基本 上 都 不 言 自明 ， 不 过 以 下 这 组 有 点 例外 。 


口 do0nEach() 
这 个 操作 符 可 以 为 每 个 Notification 所 调用 ， 即 onNext()、onCompleted() 和 onError()。 
它 既 可 以 接收 每 个 Notification 调用 的 lambda 表达 式 ， 也 可 以 接收 一 个 Observer。 























口 do0nTerminate() 
出 现 onCompleted() 或 onError() 时 ， 都 会 触发 该 回调 。 两 者 无 法 进行 区 分 ， 所 以 最 好 
单独 使 用 doonCompleted() 或 doonError()。 











7.4.2 ”测量 和 监控 
回调 不 仅 用 于 日 志 记录 。 如 果 应 用 程序 内 置 各 种 遥测 探 针 〈 比 如 简单 的 计数 器 、 定 时 器 、 
分 布 直方 图 等 )， 并 且 能 够 在 外 部 进行 访问 ， 那 么 这 会 极 大 地 减少 问题 排查 的 时 间 ， 我 们 
也 能 很 好 地 观察 应 用 程序 正在 做 什么 。 在 简化 指标 的 收集 和 发 布 方面 ， 有 很 多 可 用 的 库 ， 
比如 Dropwizard metrics。 在 使 用 这 个 库 之 前 ， 需 要 一 些 初始 搭建 工作 ， 如 下 所 示 。 

import com.codahale.metrics.MetricRegistry; 


import com.codahale.metrics.S1lf4jReporter; 
import org.slf4j.LoggerFactory; 






































MetricRegistry metricRegistry = new MetricRegistry(); 

Slf4jReporter reporter = Slf4jReporter 
.forRegistry(metricRegistry) 
.OutputTo(LoggerFactory.getLogger(SomeClass.class)) 
.build(); 

reporter.start(1, TimeUnit.SECONDS); 
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MetricRegistry 是 各 种 指标 的 一 个 工厂 。 另 外 ， 还 搭建 了 一 个 SLf4jReporter， 它 会 将 当 
前 的 统计 快照 推送 至 给 定 的 SLF4J logger。 除 此 之 外 ， 还 有 推送 至 Graphite 和 Ganglia 的 
reporter。 简 单 配置 完成 之 后 ， 我 们 就 可 以 监控 自己 的 系统 了 。 
我 们 能 想到 的 最 简单 的 指标 就 是 Counter， 它 可 以 递增 或 递减 。 你 可 以 用 它 来 测量 通过 流 
的 事件 数量 ， 如 下 所 示 。 

final Counter items = metricRegistry.counter("items"); 

observable 


.do0nNext(x -> items.inc()) 
.SUbscribe(...); 


订阅 这 个 0bservable 之 后 ，Counter 就 会 显示 目前 已 经 生成 了 多 少 条 目 。 如 果 样 例 将 这 个 
信息 推送 至 外 部 的 监控 服务 器 ， 如 Graphite， 并 随 着 时 间 推 移 在 图 表 上 展现 ， 这 个 信息 会 
更 加 有 用 。 


我 们 想 要 捕获 的 男 一 个 重要 指标 ， 就 是 有 多 少 条 目 正 在 并 发 处 理 。 例 如 ，flatMap() 可 以 
很 容易 地 生成 数 百 个 其 至 更 多 的 并 发 0bservable， 并 同时 订阅 它们 。 如 果 我 们 能 够 知道 有 
多 少 个 这 样 的 Observable (考虑 一 下 处 于 打开 状态 的 数据 库 连 接 、WebSocket 等 )， 那 么 就 
可 以 在 很 大 程度 上 了 解 系 统 是 如 何 运 行 的 。 


Observable<Long> makeNetworkCall(long x) { 
/i 
































} 


Counter counter = metricRegistry.counter("counter"); 
observable 
.do0nNext(x -> counter.inc()) 
.flatMap(this: :makeNetworkCall) 
.doOnNext(x -> counter.dec()) 
.SUbscribe(...); 


当 事 件 在 上 游 出 现时 ， 样 例 递 增 这 个 计数 器 ， 事件 在 fLatMap() 后 面 出 现 (这 意味 着 某 个 
异步 操作 刚刚 发 布 了 内 容 ) 时 ， 递 减 这 个 计数 器 。 在 空 闪 的 系统 中 ， 计 数 器 的 值 始终 为 
零 ， 但 是 ， 如 果 上 游 observable 生成 了 大 量 的 事件 ， 而 makeNetworkCall() 相对 比较 慢 ， 
计数 器 的 值 就 会 部 升 ， 清 晰 标明 瓶颈 的 位 置 。 


上 述 样 例假 设 makeNetworkCaLL() 始终 只 返回 一 个 条 目 ， 并 且 永 远 不 会 失败 (不 会 以 onError() 
的 形式 完成 该 流 )。 如 果 你 想 要 测量 从 开始 订阅 内 部 0bservable (工作 开始 执行 的 时 间 ) 
到 它 完成 的 时 长 ， 那 么 也 很 简单 。 
observable 
.flatMap(x -> 
makeNetworkCall(x) 


.doOnSubscribe(counter::inc) 
.doOnTerminate(counter::dec) 



































) 


.SUbscribe(...); 


最 复杂 的 指标 之 一 是 Timer， 它 测量 了 两 个 时 间 点 之 间 的 时 长 。 我 无 意 夸 大 这 个 指标 的 价 
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值 ， 但 是 借助 它 ， 我 们 可 以 测量 网 络 调用 延迟 、 数 据 库 查询 时 间 、 用 户 响 应 时 间 等 。 测 量 
时 间 的 方式 一 般 是 获取 当前 时 间 的 快照 ， 执 行 一 些 耗 时 的 操作 ， 然 后 计算 现在 时 间 和 之 前 
时 间 的 差 值 。 这 种 方式 在 Metrics 库 中 进行 了 如 下 封装 。 


import com.codahale.metrics.Timer; 























Timer timer = metricRegistry.timer("timer"); 

Timer.Context ctx = timer.time(); 

// 一 些 宛 长 的 操作 …… 

ctx.stop(); 
这 个 API 会 将 操作 的 开始 时 间 封 装 到 Timer .Context 中 ， 并 假设 要 测试 的 代码 是 阻塞 式 的 。 
但 是 ， 如 果 我 们 想 要 测量 从 订阅 一 个 无 法 控制 的 0bservable 到 它 结束 的 时 长 ， 又 该 怎么 处 
理 呢 ? 在 这 里 ， 依 赖 doonsubscribe() 和 doonTerminate() 是 不 够 的 ， 因 为 无 法 在 它们 之 间 
传递 Timer .Context。 地 而 ，RxJava 通过 一 个 额外 的 组 合 层 解决 了 这 个 问题 。 


Observable<Long> external = //... 








Timer timer = metricRegistry.timer("timer"); 


Observable<Long> externalWithTimer = Observable 
.defer(() -> Observable.just(timer.time())) 
.flatMap(timerCtx -> 

external.doOnCompleted(timerCtx: :stop)); 


我 们 使 用 了 一 点 小 技巧 。 首 先 ， 使 用 defer() 操作 符 延 迟 了 局 动 时 间 。 通 过 这 种 方式 ， 定 
时 器 会 在 订阅 发 生 时 恰好 启动。 随后， 以 某 种 方式 将 Timer.Context 实例 替换 为 实际 想 要 
测试 的 Observable (external)。 但 是 ， 在 返回 external 0bservable 之 前 ， 停 止 运 行 计 时 
器 。 通 过 这 种 方式 ， 你 可 以 测量 任何 无 法 控制 的 Observable 订阅 和 终止 之 间 的 时 长 。 


如 果 你 需要 综合 的 、 企 业 级 的 监控 层 ， 那 么 可 以 考虑 使 用 RxJava 编写 的 Hystrix。 这 个 库 
是 第 8 章 的 一 个 研究 案例 (参见 8.2 节 )。 


7.5 “小结 


任何 反应 式 库 或 框架 的 调试 和 问题 排查 都 具有 挑战 性 ， 这 是 它们 的 异步 性 和 事件 驱动 架构 
决定 的 。RxJava 也 不 例外 ， 但 是 它 提供 了 一 些 工具 ， 使 得 开发 人 员 和 运 维 人 员 的 工作 更 加 
轻松 。 


首先 ，RxJava 拥抱 错误 ， 使 其 更 容易 处 理 和 管理 。 
其 次 ， 它 提供 了 一 些 设施 ， 实 时 监控 和 调试 流 。 
最 后 ， 它 对 单元 测试 提供 了 良好 的 支持 。 

实际 上 ， 对 于 时 间 敏 感 的 操作 符 ， 能 够 控制 系统 时 钟 是 极其 有 用 的 。 起 初 ，RxJava 的 问题 

排查 可 能 会 比较 困难 。 不 过 ， 它 提供 了 清晰 的 API 和 严格 的 契约 ， 而 不 是 表面 上 看 起 来 更 

简单 的 阻塞 式 代 码 。 后 者 可 能 存在 隐藏 的 竞 态 条 件 和 较 差 的 吞吐 量 问 题 。 
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第 8 和 章 


案例 学 > 





托 马 什 . 努 尔 凯 维 茨 〈Tomasz Nurkiewicz) 





本 章 展 示 了 使 用 RxJava 编写 实际 应 用 程序 的 用 例 。Reactive Extensions 的 API 非常 强大 ， 
但 是 首先 必须 要 有 0bservable 源 。 由 于 回 压 和 Rx 契约 的 限制 ， 从 头 编写 Observable 可 能 
是 一 件 非常 具有 挑战 性 的 事情 。 好 消息 是 ， 很 多 库 和 框架 已 经 原生 支持 RxJava。 同 时 ， 在 
一 些 具有 异步 特征 的 平台 上 ，RxJava 是 非常 有 用 的 。 


通过 本 章 的 学 习 ， 你 将 了 解 RxJava 是 如 何 改善 已 有 架构 的 设计 并 增强 其 功能 的 。 我 们 还 
会 探讨 一 些 更 高 级 的 话题 ， 这 涉及 反应 式 应 用 程序 部 署 到 生产 环境 ， 比 如 内 存 泄漏 。 当 本 
章 结束 时 ， 你 应 该 相信 RxJava 是 一 个 成 熟 和 通用 的 框架 ， 足 以 在 真正 的 现代 应 用 程序 中 
实现 各 种 用 例 。 


8.1 使 用 RxJava 进 行 Android 开 发 


RxJava 在 Android 开发 人 员 中 非常 流行 。 首先， 图 形 化 用 户 界面 本 质 上 是 事件 驱动 的 ， 因 
为 事件 来 源 于 各 种 操作 ， 比 如 键盘 输入 或 鼠标 移动 。 其 次 ， 与 Swing 和 其 他 GUI 环境 类 
似 ，Android 对 线程 的 要 求 非常 苛刻 。 不 应 该 阻塞 Android 主线 程 ， 以 免 造成 用 户 界面 的 
冻结 ， 但 是 用 户 界面 的 所 有 更 新 必须 在 主线 程 中 进行 。 这 些 问 题 会 在 8.1.3 节 中 得 到 解决 。 
但 是 ， 如 果 说 在 Android 中 使 用 RxJava 只 需要 学 习 一 件 事 ， 那 么 一 定 不 要 错过 接 下 来 的 部 
分 。 本 节 将 阐述 内 存 泄漏 的 问题 ， 以 及 如 何 轻 松 避 免 它们 。 


8.1.1 ”避免 Activity 中 的 内 存 泄漏 
Android 特有 的 一 个 缺陷 就 是 Activity 相关 的 内 存 泄漏 。 这 种 问题 的 发 生 场景 是 0bserver 
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持 有 对 任意 GUI 组 件 的 强 引 用 ， 而 这 个 GUI 组 件 又 反 过 来 引用 了 整个 父 Activity 实例 。 
当 你 切换 屏幕 界面 或 者 按 下 返回 按钮 时 ，Android 就 会 销毁 当前 的 Activity 并 最 终 对 其 进 
行 垃圾 回收 。Activity 是 非常 大 的 对 象 ， 所 以 即时 对 它们 进行 清理 是 非常 重要 的 。 但 是 ， 
如 果 0bserver 持 有 了 对 这 种 Activity 的 引用 ， 它 可 能 永远 不 会 被 垃圾 回收 ， 从 而 引起 内 
存 泄漏 ， 最 终 设备 会 彻底 终止 这 个 应 用 程序 。 以 下 面 的 代码 为 例 。 


public class MainActivity extends AppCompatActivity { 

















private final byte[] blob = new byte[32 * 1024 * 1024]; 


@Override 
protected void onCreate(Bundle savedInstanceState) { 
super .onCreate(savedInstanceState); 
TextView text = (TextView) findViewById(R.id.textView); 
Observable 
.interval(100, TimeUnit.MILLISECONDS) 
.observeOnNn(AndroidSchedulers.mainThread()) 
.Subscribe(x -> { 
text.setText(Long.toString(x)); 
]); 


} 


这 里 的 blob 字段 只 是 为 了 加 快 出 现 内 存 泄漏 的 效果 ， 我 们 可 以 将 MainActivity 设想 为 一 
个 相当 复杂 的 对 象 树 。 这 个 简单 的 应 用 程序 看 上 去 并 没有 什么 问题 。 每 隔 100 毫秒 ， 它 就 
会 使 用 当前 计数 器 的 值 更 新 文本 域 。 但 是 ， 如 果 你 在 设备 上 多 次 旋转 屏幕 ， 应 用 程序 就 会 
因为 outofMemoryError 而 出 现 崩溃 。 这 里 发 生 的 事情 如 下 所 示 。 


(1) 创建 MainActivity， 在 执行 onCreate() 的 时 候 ， 订 阅 interval()。 

(2) 每 隔 100 毫秒 ， 使 用 当前 计数 器 的 值 更 新 text。 可 以 先 忽略 mainThread() 这 个 Scheduler， 
8.1.3 节 会 对 其 进行 介绍 。 

(3) 设备 改变 了 方向 。 

(4) MainActivity 被 销毁 ， 继 而 创建 一 个 新 的 MainActivity，onCreate() 被 再 次 执行 。 

(5) 目前 有 两 个 Observable.interval() 在 运行 ， 因 为 没有 取消 对 第 一 个 Observable 的 订阅 。 


实际 上 ， 现 在 有 两 个 0Observable.interval() 在 运行 ， 其 中 一 个 是 已 销毁 Activity 的 残留 
物 ， 但 这 还 不 是 最 糟糕 的 。interval() 操作 符 会 使 用 一 2 (通过 computation() 
Scheduler) 来 发 布 计数 器 事件 。 这 些 事 件 随 后 会 传递 给 Observer， 其 中 有 个 Observer 会 
持 有 对 TextView 的 引用 ， 而 TextView 会 反 过 来 持 有 对 旧 MainActivity 的 引用 。 现 在 ， 发 
布 interval() 事件 的 线程 成 了 新 的 GC 根 ， 所 以 它 直 接 或 间接 引用 的 所 有 对 象 都 不 能 ; 
行 垃圾 回收 。 换 句 话说， 即便 第 一 个 MainActivity 实例 销毁 了 ， 它 也 不 能 被 垃圾 回收 ， 
blob 占据 的 内 存 也 无 法 进行 释放 。 每 次 方向 变化 (或 者 每 当 Android 决定 要 销毁 特定 的 
Activity) 都 会 增加 内 存 的 泄漏 。 解 决 方案 其 实 非常 简单 : 取消 订阅 ， 让 interval() 知道 
何 时 不 再 需要 它 (参见 2.3 节 )。 就 像 onCreate() 一 样 ，Android 也 有 一 个 销毁 回调 ， 名 为 
onDestroy()， 如 下 所 示 。 
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private Subscription subscription; 


@Override 
protected void onCreate(Bundle savedInstanceState) { 


fi 

subscription = Observable 
.interval(100, TimeUnit.MILLISECONDS) 
.observeOn(AndroidSchedulers.mainThread()) 
.Subscribe(x -> { 

text.setText(Long.toString(x)); 
]); 
} 


@Override 

protected void onDestroy() { 
super .onDestroy(); 
subscription.unsubscribe(); 


} 


创建 bbservable 的 时 候 ， 是 作为 Activity 生命 周期 的 一 部 分 。 如 果 Activity 销毁 ， 需 要 
确保 取消 对 0bservable 的 订阅 。 调 用 unsusbcribe() 会 解除 0bserver 与 Observable 的 关 
联 ， 这 样 ， 就 能 进行 垃圾 回收 了 。 现 在 ， 整 个 MainActivity 连同 0bserver 都 可 以 进行 回 
收 了 。 同 时 ，interval() 本 身 也 不 会 再 发 布 事件 ， 因 为 没有 人 对 其 进行 监听 。 实 现 了 双赢 
的 效果 。 

如 果 要 在 某 个 Activity 中 创建 多 个 Observable， 那 么 持 有 对 所 有 Subscription 的 引用 可 
能 会 变 得 非常 烦琐 。 在 这 种 情况 下 ，Conposttesubscriptton 是 一 个 非常 便利 的 容器 。 每 个 
Subscription 都 可 以 插入 CompositeSubscription 中 ， 在 销毁 的 时 候 ， 一 步 就 能 轻松 地 对 它 
们 全 部 取消 订阅 ， 如 下 所 示 。 


private CompositeSubscription allSubscriptions = new CompositeSubscription(); 















































@Override 
protected void onCreate(Bundle savedInstanceState) { 
//... 

Subscription subscription = Observable 
.interval(100, TimeUnit.MILLISECONDS) 
.ObserveOn(AndroidSchedulers.mainThread()) 
.Subscribe(x -> { 

text.setText(Long.toString(x)); 
]); 
allSubscriptions.add(subscription); 


} 


@Override 

protected void onDestroy() { 
super .onDestroy(); 
allSubscriptions.unsubscribe(); 


} 


值得 一 提 的 是 ， 在 任何 环境 下 ， 如 果 不 再 使 用 革 个 0bservabte， 对 其 取消 订阅 都 是 一 种 好 
的 实践 。 在 资源 有 限 的 移动 设备 中 ， 这 一 点 显得 尤为 重要 。 既 然 你 已 经 了 解 了 Android 中 
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内 存 管理 的 缺陷 ， 接 下 来 就 可 以 重新 设计 我 们 的 移动 应 用 程序 了 。 首 先 探讨 Retrofit， 这 是 
一 个 内 置 了 RxJava 支持 的 HTTP 客户 端 ， 在 移动 环境 中 非常 流行 。 


8.1.2 ”Retrofit 对 RxJava 的 原生 支持 


Retrofit 是 一 个 发 送 HTTP 请 求 的 库 ， 在 Android 生态 系统 中 的 使 用 尤为 普遍 。 它 并 不 局 限 
于 Android， 也 不 是 HTTP 客户 端 方案 的 唯一 选择 。 但 是 ， 因 为 它 对 RxJava 提供 了 支持 ， 
所 以 是 移动 应 用 程序 很 好 的 可 选 方案 。 它 不 仅 适 用 于 充分 考虑 到 RxJava 的 场景 ， 也 适用 
于 仅仅 想 要 恰当 处 理 HTTP 代码 的 场景 。 在 网 络 相 关 的 代码 中 使 用 RxJava 的 优势 ， 在 于 
它 能 够 在 线程 之 间 方 便 地 进行 切换 。 在 体验 Retrofit 之 前 ， 我 们 需要 添加 如 下 依赖 ， 包 括 
库 本 身 、 针 对 RxJava 的 适配器 以 及 针对 Jackson JSON 解析 功能 的 转换 器 。 

compile 'com.squareup.retrofit2:retrofit:2.0.1' 


compile "com.squareup.retrofit2:adapter-rxjava:2.0.1' 
compile 'com.squareup.retrofit2:converter-jackson:2.0.1" 


Retrofit 倡导 以 类 型 安全 的 方式 与 RESTful 服务 进行 交互 ， 它 要 求 首先 声明 一 个 Java 接口 ， 
但 是 不 需要 实现 。 这 个 接口 随后 会 被 透明 地 转换 成 一 个 HTTP 请 求 。 出 于 练习 的 目的 ， 样 
例会 与 Meetup API 进行 交互 ， 这 是 一 个 用 于 组 织 活动 的 流行 服务 ， 其 中 的 一 个 端点 能 够 返 
回 指定 位 置 附近 的 城市 列表 。 


import retrofit2.http.GET; 
import retrofit2.http.Query; 





















































public interface MeetupApi { 


@GET("/2/cities") 
Observable<Cities> listCities( 
@Query("lat") double lat, 
@Query("lon") double lon 
); 


} 


Retrofit 将 对 ListCities() 的 方法 调用 转换 为 网 络 调 用 。 在 内 部 ， 发 起 对 /2/cities?lat= 
.….&lon=... 资源 的 HTTP GET 请 求 。 请 注意 返回 类 型 。 首 先 ， 我们 已 经 有 了 强 类 型 
的 cities， 而 不 是 使 用 String 或 弱 类 型 的 身 套 Map (map-of-maps)。 但 是 更 重要 的 是 ， 
Cities 源 于 一 个 Observable， 响 应 到 达 的 时 候 ，0bservable 会 发 布 这 个 对 象 。Cities 类 了 上映 
射 了 在 JSON 中 从 服务 器 端 接收 到 的 大 部 分 字段 ， 这 里 省 略 了 getter 和 setter。 


public class Cities { 
private List<City> results; 

















} 


public class City { 
private String city; 
private String country; 
private Double distance; 
private Integer id; 
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private Double lat; 

private String localizedCountryName; 
private Double lon; 

private Integer memberCount; 

private Integer ranking; 

private String zip; 


} 


这 样 的 方式 很 好 地 平衡 了 抽象 (使 用 高 层级 的 理念 ， 如 方法 调用 和 强 类 型 的 响应 ) 和 底层 
细节 (网络 调用 的 异步 性 )。 尽 管 HTTP 具有 请 求 一 响应 的 语义 ， 但 是 对 不 可 避免 的 延迟 
使 用 0bservable 进行 抽象 ， 这 样 它 就 无 法 隐藏 在 精 糕 的 阻塞 式 RPC (远程 过 程 调用 ) 抽象 
后 面 了 。 令 人 遗憾 的 是 ， 为 了 与 这 个 特殊 的 API 进行 交互 ， 还 需要 配置 很 多 胶水 代码 。 具 
体 的 情况 可 能 略 有 差异 ， 重 要 的 是 了 解 正确 解析 JSON 响应 的 步骤 。 

import com.fasterxml.jackson.databind.DeserializationFeature; 

import com.fasterxmL.jackson.databind.0bjectMapper; 

import com.fasterxml.jackson.databind.PropertyNamingStrategy; 

import retrofit2.Retrofit; 


import retrofit2.adapter.rxjava.RxJavaCaLLAdapterFactory; 
import retrofit2.converter.jackson.JacksonConverterFactory; 



































ObjectMapper objectMapper = new ObjectMapper(); 

objectMapper .setPropertyNamingStrategy( 
PropertyNamingStrategy.CAMEL_CASE_TO_LONER_CASE_NITH_UNDERSCORES ) ; 

objectMapper .configure( 
DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false); 


Retrofit retrofit = new Retrofit.Builder() 
.baseUrl("https://api.meetuyp.com/") 
.addCallAdapterFactory( 

RxJavaCallAdapterFactory.create()) 
.addConverterFactory( 

JacksonConverterFactory.create(objectMapper )) 
.build(); 


首先 ， 需 要 优化 一 下 Jackson 库 中 的 0bjectMapper， 从 而 无 缝 地 将 下 划 线 的 字段 名 转换 
为 Java Bean 使 用 的 驼峰 式 命名 约定 ， 比 如 ，JSON 中 的 localized_country_name 转换 为 
City 类 中 的 localizedCountryName。 其 次 ， 我 们 想 要 忽略 bean 类 中 没有 进行 映射 的 字段 。 
JSON API 会 进行 演化 ， 添 加 一 些 客户 端 尚未 支持 的 新 字段 。 比 较 合理 的 一 种 默认 行为 就 
是 忽略 掉 这 些 字段 ， 只 使 用 对 我 们 有 意义 的 字段 。 这 样 ， 服 务 器 端 可 以 给 响应 添加 新 的 字 
段 ， 而 不 会 破坏 现 有 的 客户 端 。 


有 了 Retrofit 之 后 ， 我 们 就 可 以 合成 MeetupApi 实现 了 。 在 整个 客户 端 代码 中 ， 都 可 以 使 用 
这 个 实现 类 。 











MeetupApi meetup = retrofit.create(MeetupApi .class); 


最 后 ， 借 助 MeetupApi， 就 可 以 发 送 HTTP 请 求 并 发 挥 RxJava 的 威力 了 。 接 下 来 ， 构 建 
个 更 综合 的 样 例 。 首 先 ， 使 用 Meetup API 获取 给 定位 置 附近 所 有 城镇 的 列表 。 
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double warsawLat = 52.229841; 

double warsawLon = 21.011736; 

Observable<Cities> cities = meetup.listCities(warsawLat, warsawLon); 

Observable<City> cityObs = cities 
.concatMapIterable(Cities::getResults); 

Observable<String> map = cityObs 
.filter(city -> city.distanceTo(warsawLat, warsawLon) < 50) 
.map(City::getCity); 


先 使 用 concatMapIterable() 扩展 只 包含 一 个 条 目的 Observable<Cities>， 将 找到 的 每 个 城 
市 放 到 0bservable<City> 中 。 然 后 ， 过 滤 距 离 原始 位 置 小 于 50 公里 的 城市 。 最 后 ， 将 城市 
的 名 称 抽 取出 来 。 下 一 个 目标 是 查询 华沙 附近 每 个 城市 的 人 口 数量 ， 看 一 下 半径 50 公里 内 
有 多 少 人 居住 。 为 了 实现 这 一 点 ， 我 们 必须 查询 GeoNames 提供 的 另外 一 个 API。 这 个 方法 
能 够 根据 给 定 的 名 称 查询 位 置 ， 返 回 其 人 口 。 我 们 将 再 次 使 用 Retrofit 来 连接 这 个 API。 


public interface GeoNames { 











@GET("/searchJSON") 
Observable<SearchResult> search( 
@Query("q") String query， 
@Query("maxRows") int maxRows, 
@Query("style") String style, 
@Query("username") String Username ) ; 


} 
样 例 必须 还 要 有 一 个 JSON 对 象 映射 到 数据 对 象 ( 这 里 省 略 了 getter 和 setter) 。 


class SearchResult { 
private List<Geoname> geonames = new ArrayList<>(); 


} 


public class Geoname { 
private String lat; 
private String lng; 
private Integer geonameId; 
private Integer population; 
private String countryCode; 
private String name; 


} 
实例 化 GeoNames 的 方式 与 MeetupApi 类 似 。 


GeoNames geoNames = new Retrofit.Builder() 
.baseUrl("http://api.geonames.org") 
.addCaLLAdapterFactory(RxJavaCaLLAdapterFactory.create()) 
.addConverterFactory(]JacksonConverterFactory.create(objectMapper ) ) 
.build() 

.Create(GeoNames .class); 


突然 之 间 ， 示 例 应 用 程序 使 用 了 两 个 不 同 的 API， 但 是 将 它们 统一 组 合 了 起 来 。 查 询 
GeoNames API 获取 每 个 城市 的 名 称 并 抽取 人 口 数量 。 
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Observable<Long> totaLPopuLation = meetup 
.listCities(warsawLat, warsawLon) 
.ConcatMapIterable(Cities::getResults) 
.filter(city -> city.distanceTo(warsawLat, warsawLon) < 50) 
.map(City::getCity) 
.flatMap(geoNames: :populationOf) 
.reduce(0OL, (x, y) -> x + y); 


如 果 你 稍微 思考 一 下 ， 会 发 现 上 面 的 代码 以 非常 简洁 的 方式 做 了 大 量 的 工作 。 首 先 ， 它 
请 求 MeetupApi 获取 城市 组 成 的 一 个 列表 。 随 后 ， 获 取 了 每 个 城市 的 人 口 数 量 。 接 下 来 ， 
借助 reduce() 对 人 口 数量 的 响应 (可 能 会 异步 返回 ) 进行 求 和 操作 。 最 后 ， 整 个 计算 管 
道 以 Observable<Long> 结束 ， 所 有 城市 的 人 口 累 积 计算 完成 时 ， 会 发 布 出 一 个 Long 类 型 
的 值 。 这 展示 了 RxJava 真正 的 威力 ， 展 现 了 不 同 来 源 的 流 如 何 无 颖 组 合 在 一 起 。 例 如 ， 
population0f() 方法 实际 上 是 一 个 非常 复杂 的 操作 符 链 ， 它 会 对 GeoNames 发 起 HTTP 请 
求 并 根据 城市 名 称 抽取 人 口 数 量 信息 。 


public interface GeoNames { 












































default Observable<Integer> populationOof(String query) { 
return search(query) 

.ConcatMapIterable(SearchResult: :getGeonames) 
.map(Geoname: :getPopulation) 
.filter(p -> p != null) 
.singleOrDefault(0) 
.doOnError(th -> 
log.warn("Falling back to 0 for {}", query, th)) 
.OnErrorReturn(th -> 0) 
.SubscribeOn(Schedulers.io()); 


} 


default Observable<SearchResult> search(String query) { 
return search(query, 1, "LONG", "some_user"); 


} 


@GET("/searchJSON") 

Observable<SearchResult> search( 
QQuery("q") String query, 
@Query("maxRows") int maxRows, 
@Query("style") String style, 
@Query("username") String Username 


); 
} 


search() 方法 在 代码 底部 采用 默认 方法 进行 了 包装 ， 所 以 它 非 常 易 于 使 用 。 在 接收 到 以 
JSON 包装 的 SearchResult 对 象 之 后 ， 样 例 将 其 拆 解 为 独立 的 搜索 结果 ， 确 保 在 响应 中 不 
会 出 现 缺少 人 口 信息 的 情况 。 如 果 出 现 了 错误 ， 将 会 返回 0。 最 后 ， 保 证 每 个 人 口 信息 的 
查询 都 会 在 一 个 io() 调度 器 中 执行 ， 以 实现 更 好 的 并 发 性 。 在 这 里 ，subscribeon() 实际 
上 至 关 重 要 。 如 果 没 有 它 ， 每 个 城市 对 人 口 信息 的 请 求 都 是 序列 化 的 ， 会 极 大 地 增加 整体 
的 延迟 。 但 是 ，flLatMap() 会 对 每 个 城市 调用 population0f() 方 法， 并 在 需要 的 时 候 进 行 
订阅 。 这 样 ， 每 个 城市 的 数据 都 会 并 发 获取 。 实 际 上 ， 还 可 以 为 获取 人 口 数据 的 请 求 添 
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加 一 个 timeout() 操作 符 ， 从 而 实现 更 好 的 响应 时 间 ， 而 代价 是 不 完整 的 数据 。 如 有 果 没 有 
RxJava， 实 现 这 样 的 场景 会 需要 大 量 手动 线程 池 集 成 。 即 便 使 用 CompletableFuture (参见 
5.4 节 )， 这 个 任务 也 并 不 简单 。 但 是 ，RxJava 凭借 非 侵 入 性 并 发 和 强大 的 操作 符 ， 能 够 很 
轻松 地 编写 简洁 且 易 于 理解 的 代码 。 


将 Retrofit 驱动 的 两 个 不 同 API 组 合 起 来 ， 运 行 效果 非常 好 。 我 们 还 可 以 将 完全 不 相关 的 
Observable 组 合 在 一 起 ， 比 如 一 个 来 源 于 Retrofit， 另 一 个 来 源 于 JDBC 调用 ， 还 有 一 个 接 
收 的 是 来 自 JMS 的 消息 。 这 些 用 例 都 很 容易 实现 ， 它 们 既 没 有 泄漏 抽象 ， 也 没有 提供 关于 
底层 流 实 现 性 质 的 过 多 细节 。 


8.1.3 Android 中 的 调度 器 


每 个 Android 开发 人 员 可 能 都 会 犯 的 第 一 个 错误 就 是 阻塞 UI 线程 。 在 Android 中 有 一 个 指 
定 的 主线 程 ， 它 会 与 用 户 界 面 (UI) 进行 双向 交互 。 不 仅 原生 组 件 的 回调 要 在 主线 程 中 调 
用 处 理 器 ， 组 件 的 更 新 (更 新 标签 、 绘 制 ) 也 必须 在 主线 程 中 。 这 种 限制 会 极 大 地 简化 UI 
的 内 部 架构 ， 但 是 也 有 以 下 严重 的 缺点 。 


如 果 在 回调 处 理 中 尝试 进行 耗 时 的 操作 〈 一 般 是 阻塞 式 的 网 络 调用 ) ， 这 个 UI 事件 会 阻 
碍 其 他 UI 事件 的 处 理 ， 从 而 导致 UI 界面 冻结 。 最 终 ， 操 作 系统 会 终止 这 种 行为 有 问 
更 新 UI 的 操作 (比如 阻塞 式 网 络 调 用 完成 的 时 候 ) 必须 在 主线 程 中 运行 。 我 们 必须 以 
某 种 方式 请 求 操作 系统 在 主线 程 中 调用 UI 更 新 的 代码 。 


令 人 兴奋 的 是 ，RxJava 对 此 有 两 种 内 置 的 机 制 。 我 们 可 以 使 用 subscribeon() 在 后 台 运 行 
一 些 具 有 副作用 的 任务 ， 并 且 能 够 很 容易 地 通过 observe0n() 跳 回 主线 程 。4.9.2 节 对 这 两 
个 操作 符 进 行 了 详细 介绍 ， 它 们 非常 适合 Android 的 使 用 场景 。 我 们 需要 的 仅仅 是 一 个 特 
殊 的 Scheduler ， 它 能 够 感知 Android 环境 及 其 主线 程 。 这 个 Scheduler 已 经 在 4.9.1 市 中 
实现 了 ， 幸 而 ， 这 里 并 不 需要 自行 实现 这 个 Scheduler。 要 开始 在 Android 中 使 用 RxJava 
的 旅程 ， 你 需要 添加 下 面 这 个 小 的 依赖 。 


compile 'io.reactivex:rxandroid:1.1.0" 


这 个 小 的 库 会 将 Androidschedulers 类 添加 到 CLASSPATH 中 。 如 果 想 要 在 Android 中 使 用 
RxJava 编写 并 发 代码 ， 这 是 必 备 的 。 我 们 还 是 举例 来 阐述 Androidschedulers 的 用 法 。 在 
下 面 的 例子 中 ， 我 们 将 会 调用 Meetup API (参见 8.1.2 节 )， 获 取 指 定位 置 附近 的 城市 列表 
并 将 它们 展现 出 来 。 


button.setOnClickListener(new View.OnClickListener() { 
@Override 
public void onClick(View view) { 
meetup 
.listCities(52.229841, 21.011736) 
.ConcatMapIterabLe(extractCities()) 
.map(toCityName()) 
.toList() 
.SubscribeOn(Schedulers.io()) 
.ObserveOn(AndroidSchedulers.mainThread()) 
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.Subscribe( 
putOnListView() ， 
displayError()); 


}); 








本 章 是 全 书 中 唯一 没有 使 用 Java 8 中 的 lambda 表达 式 的 地 方 。 因 为 撰写 本 章 的 时 候 ， 


Android 只 支持 Java 7， 不 允许 使 用 原生 的 闲 包 。” 
独 的 方法 中 ， 以 提升 可 读 性 。 如 果 你 觉得 这 种 方式 过 于 烦琐 〈 即 便 是 不 使 用 RxJava 的 场 
景 )， 那 么 可 以 尝试 体验 一 下 retrolambda， 它 能 够 将 lambda 表达 式 向 后 迁移 至 旧版 本 上 
Java， 并 且 能 够 在 Android 上 运行 。 在 普通 的 Android 中 ， 所 有 的 转换 和 回调 将 会 如 下 

















所 示 。 


//Cities::getResults 
Funci<Cities, Iterable<City>> extractCities() { 
return new Funci<Cities, Iterable<City>>() { 
@Override 
public Iterable<City> call(Cities cities) { 
return cities.getResults(); 
} 
上 


//City::getCity 
Funci<City, String> toCityName() { 
return new Funci<City, String>() { 
@Override 
public String call(City city) { 
return city.getCity(); 
} 
}; 
} 


//cities -> listView.setAdapter(...) 
Action1<List<String>> putOnListView() { 
return new Action1i<List<String>>() { 
@Override 
public void call(List<String> cities) { 
listView.setAdapter (new ArrayAdapter( 
MainActivity.this, R.layout.list, cities)); 
} 
}; 
} 


//throwable -> {...} 
Action1<ThrowabLe> displayError() { 
return new Action1<ThrowabLe>() { 
@Override 





注 1: 这 会 随 着 Android N 的 发 布 而 改变 。 更 多 相关 信息 ， 请 参阅 使 用 Java 8 的 功能 指南 。 


因此 ， 我 们 将 匿名 内 部 类 抽取 到 了 单 








了 
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public void call(Throwable throwable) { 
Log.e(TAG, "Error", throwable); 
Toast.makeText(MainActivity.this, 
"Unable to load cities", 
Toast .LENGTH_SHORT) 
.Show(); 
} 
}; 
} 
接 下 来 描述 一 下 都 发 生 了 什么 。 点 击 按钮 的 时 候 (参见 8.1.4 节 )， 样 例会 通过 Retrofit 发 
起 一 个 HTTP 请 求 。Retrofit 会 生成 一 个 0bservable<Cities>， 随 后 只 抽取 相关 的 信息 对 其 
进行 进一步 的 转换 。 最 终 ， 会 得 到 代表 附近 城市 的 List<string>。 这 个 列表 最 终 会 在 界面 
上 展现 出 来 。 


这 两 个 调度 器 的 使 用 至 关 重 要 。 如 果 没 有 subscribe0n()，Retrotfit 将 会 使 用 调用 者 的 线 
程 来 发 起 HTTP 调用 ， 这 会 导致 Observable 阻 寨 。 这 意味 着 ，HTTP 请 求 将 会 试图 阻 
塞 Android 主线 程 ， 它 会 立即 被 操作 系统 执行 ， 并 且 会 由 于 出 现 NetworkonMainThread- 
Exception 而 失败 。 按 照 传统 方式 在 后 台 运 行 网 络 代 码 ， 要 么 创建 新 的 Thread， 要 么 使 
用 AsyncTask。subscribeon() 的 优势 非常 明显 : 代码 更 加 人 简洁， 侵入 性 更 低 ， 而 且 通 过 
onError 通知 提供 了 内 置 的 声明 式 错误 处 理 。 


对 observeon() 的 调用 同等 重要 。 所 有 的 转换 完成 之 后 ， 我 们 仅 在 主线 程 中 调用 UI 
更 新 ， 因 为 希望 主线 程 上 的 处 理 越 少 越 好 。 如 果 没 有 observeon() 将 执行 切换 到 
mainThread()， 那 么 Observable 会 尝试 更 新 后 台 线 程 中 的 ListVview， 而 这 会 由 于 出 现 
CalledFromWrongThreadException 而 立即 失败 。 同 样 ，observe0n() 要 比 android.os.Handler 
类 (Androidschedulers.mainThread() 底层 用 到 了 这 种 方式 ) 中 的 postDelayed() 更 加 便利 。 
调度 器 的 灵活 性 和 API 的 简洁 性 对 于 Android 开发 人 员 非 常 有 吸引 力 。RxJava 提供 了 一 种 
更 简单 、 整 洁 和 安全 的 方式 来 处 理 移动 设备 上 并 发 编程 的 复杂 性 。 

关于 内 存 泄漏 

上 面 的 样 例 有 一 个 主要 的 缺陷 ， 它 可 能 会 导致 内 存 泄漏 。0bserver 持 有 了 对 

这 个 封闭 的 Android Activity 的 引用 ， 而 且 会 存活 得 更 久 。 这 个 问题 已 经 在 
8.1.1 市 进行 了 阐述 和 解决 。 
















































































8.1.4 ”将 Ul 事件 作为 流 


从 语义 层面 上 讲 ，RxJava 的 目标 是 避免 出 现 回调 地 狱 ,这 是 通过 将 内 格 回 调 赫 换 为 声明 
式 转换 实现 的 。 因 此 ， 将 0bservable 封闭 到 set0nCLickListener() 中 看 上 去 并 不 能 让 
人 满意 。 幸 好 ， 有 一 个 库 能 够 将 Android UI 事件 转换 为 流 。 只 需要 将 如 下 依赖 添加 到 项 
目 中 。 


compile 'com.jakewharton.rxbinding:rxbinding:0.4.0" 


现在 开始 ， 就 可 以 将 命令 式 的 回调 注册 替换 为 便利 的 管道 。 
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RxView 

.Clicks(button) 
.flatMap( listCities(52.229841, 21.011736)) 
.delay(2, TimeUnit.SECONDS) 
.concatMapIterable(extractCities()) 
.map(toCityName()) 
.toList() 
.SubscribeOn(Schedulers.io()) 
.observeOn(AndroidSchedulers.mainThread()) 
.Subscribe( 

putOnListView( ) ， 

displayError()); 


Func1i<Void, Observable<Cities>> listCities(final double lat, final double Lon) { 
return new Funci<Void, Observable<Cities>>() { 
@Override 
public Observable<Cities> call(Void aVoid) { 
return meetup.listCities(lat, lon); 
} 
}; 
} 
现在 ， 不 再 通过 注册 回调 在 本 地 创建 和 转换 0Observable， 而 是 首先 使 用 Observable<Void> 
代表 单 击 按钮 。 单 击 按钮 不 会 传递 任何 信息 ， 所 以 它 是 void。 每 个 单 击 事件 会 触发 一 个 异 
步 的 HITP 请 求 ， 该 请 求 会 返回 0bservable<Cities>。 其 他 的 内 容 完 全 相同 。 如 果 你 认为 
这 样 做 只 是 提升 了 可 读 性 ， 那 么 考虑 一 下 组 合 多 个 GUI 事件 流 的 场景 。 


假设 有 两 个 文本 域 ， 其 中 一 个 用 来 输入 纬度 ， 另 一 个 用 来 输入 经 度 。 它 们 中 的 任何 一 个 发 
生变 化 的 时 候 ， 都 会 发 起 一 个 HTTP 请 求 ， 查 看 该 位 置 附 近 所 有 的 城市 。 但 是 ， 为 了 避免 
用 户 输入 期 间 产 生 不 必要 的 网 络 流量 ,我们 想 要 实现 一 个 特定 的 延迟 。 只 有 1 秒 内 文本 域 
的 值 没 有 变化 的 时 候 ， 才 会 初始 化 网 络 请 求 。 这 非常 类 似 于 自动 补 全 的 文本 域 ， 它 有 一 
个 轻微 的 延迟 ， 避 免 产 生 大 量 的 网 络 使 用 。 但 是 本 例 必 须要 同时 考虑 两 个 输入 域 。 使 用 
RxJava 和 RxBinding 的 实现 非常 优雅 。 









































import android.widget.EditText; 
import com.jakewharton.rxbinding.widget.RxTextView; 
import com.jakewharton.rxbinding.widget.TextViewAfterTextChangeEvent; 


EditText LatText = //... 
EditText LonText = //... 


Observable<Double> latChanges = RxTextView 
.afterTextChangeEvents(latText) 
.flatMap(toDouble()); 

Observable<Double> lonChanges = RxTextView 
.afterTextChangeEvents(LonText) 
.flatMap(toDouble()); 


Observable<Cities> cities = Observable 
.combineLatest(latChanges, lonChanges, topair()) 
.debounce(1, TimeUnit.SECONDS) 
.flatMap(listCitiesNear()); 





234 | 第 8 章 


所 有 转换 如 下 所 示 〈 请 注意 ， 在 不 能 使 用 lambda 的 时 候 ， 代 码 会 变 得 非常 烦琐 ) 。 


Func1<TextViewAfterTextChangeEvent，0ObservabLe<DoubLe>> toDouble() { 
return new Funcl<TextViewAfterTextChangeEvent, Observable<Double>>() { 
@Override 
public Observable<Double> call(TextViewAfterTextChangeEvent e) { 
String s = e.editable().toString(); 
try { 
return Observable.just(Double.parseDouble(s)); 
} catch (NumberFormatException e) { 
return Observable.empty(); 
} 
} 
}; 
} 


//return Pair::new 
Func2<Double, Double, Pair<Double, Double>> topair() { 
return new Func2<Double, Double, Pair<Double, Double>>() { 
@Override 
public Pair<Double, Double> call(Double lat, Double lon) { 
return new Pair<>(lat, lon); 
} 
}; 
} 


//return LatLon -> meetup.listCities(latLon.first, latLon.second) 
Func1i<Pair<Double, Double>, Observable<Cities>> listCitiesNear() { 
return new Func1i<Pair<Double, Double>, Observable<Cities>>() { 
@Override 
public Observable<Cities> call(Pair<Double, Double> latLon) { 
return meetup.listCities(latLon.first, latLon.second); 
} 
}; 
} 


首先 ， 每 次 内 容 发 生变 化 的 上 时候 ，RxTextView.afterTextChangeEvents() 就 会 转换 EditText 
调用 的 声明 式 回调 。 分 别 为 经 度 和 纬度 创建 两 个 这 样 的 流 。 在 运行 时 ， 样 例会 将 
TextViewAfterTextChangeEvent 转换 为 double 类 型 ， 此 时 会 丢弃 不 合法 的 输入 。 有 了 两 个 
double 类 型 的 流 之 后 ， 使 用 combineLatest() 将 它们 联合 起 来 ， 每 当 任何 一 个 输入 发 生变 





化 ， 样 例 就 会 接收 成 对 的 流 。 最 后 一 块 内 容 是 debounce() (参见 6.1.4 节 )， 在 形成 这 检 





个 配对 信息 之 前 ， 它 会 等 待 1 秒 ， 防 止 随后 立即 对 文本 域 进行 编辑 (同时 适用 于 经 度 逢 


tk 





EE 














度 )。 借 助 debounce()， 在 用 户 输入 的 时 候 ， 能 够 避免 不 必要 的 网 络 调 用 。 应 用 程序 的 其 


他 部 分 和 以 前 一 样 。 














这 个 示例 很 好 地 阐述 了 反应 式 编程 是 如 何 从 Retrofit 传播 到 用 户 组 件 的 ， 这 样 ， 整 个 应 用 
程序 就 变 成 了 流 的 组 合 。 不 过 要 确保 最 后 取消 了 对 afterTextChangeEvents() 的 订阅 ， 否 则 











会 导致 内 存 泄漏 。 
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8.2 ”使 用 Hystrix 管 理 失败 


分 布 式 系统 有 这 样 的 特点 : 一 台 你 甚至 不 知道 它 存在 的 计算 机 ， 如 果 它 出 现 了 故 
障 ， 有 可 能 会 导致 你 自己 的 计算 机 无 法 使 用 。 


一 一 Leslie Lamport，1987 
RxJava 有 很 多 操作 符 ， 它 们 支持 编写 可 扩展 、 反 应 式 和 有 弹性 的 应 用 程序 。 


。 通过 Scheduler 实现 声明 式 并 发 (参见 4.9 节 )。 
。 超时 (参见 7.1.3 节 ) 和 各 种 错误 处 理 机 制 (参见 7.1 节 和 7.1.4 节 )。 
。 使 用 flatMap() 实现 并 行 处 理 (参见 4.6 节 )， 同 时 限制 并 发 的 数量 (参见 3.1.5 节 )。 


不 过 ,为 了 编写 健壮 和 有 弹性 的 应 用 程序 ， 尤 其 是 在 云 环境 或 使 用 微服 务 架构 的 情况 下 ， 
我 们 需要 更 多 非 RxJava 核心 具备 的 特性 。 本 节 将 会 简要 介绍 一 下 Hystrix， 这 是 一 个 在 分 
布 式 环境 中 管理 、 隔 离 和 处 理 失败 的 库 。Hystrix 允许 包装 可 能 会 出 现 失 败 的 行为 ， 并 围绕 
这 些 代码 采取 非常 智能 的 逻辑 。 包 括 以 下 儿 点 。 


。 舱 壁 模式 (bulkhead pattern)， 即 在 一 定时 间 内 完全 切断 不 正常 的 行为 。 

。 快速 失败 ， 通 过 超时 、 限 制 并 发 、 实 现 断 路 器 (circuit breaker) 等 方式 实现 。 

。 批量 请 求 ， 通 过 将 多 个 小 的 请 求 合并 为 一 个 大 请 求实 现 。 

。 收集 、 发 布 和 可 视 化 性 能 统计 信息 。 

Hystrix 最 强大 的 功能 之 一 就 是 断路 器 ， 也 就 是 暂时 关闭 故障 依赖 的 一 种 机 制 ， 这 样 失败 就 
不 会 级 联 。 如 果 在 分 布 式 系统 中 ， 失 败 没 有 进行 恰当 地 处 理 ， 那 么 它们 很 容易 传递 到 下 游 
的 依赖 中 ， 就 像 异 常会 在 栈 中 传递 一 样 。 在 分 布 式 系统 中 ， 一 个 终端 用 户 的 请 求 可 以 轻易 
地 向 上 游 依 赖 发送 数 十 个 甚至 上 百 个 请 求 。 一 个 出 现 故 障 的 服务 ， 即 便 是 非 必 要 的 服务 ， 
都 可 能 会 导致 整个 系统 的 月 涡 ， 让 每 个 请 求 都 失败 。 


有 意思 的 是 ， 响 应 慢 的 服务 要 比 失败 的 服务 更 加 糟糕。 如 果 用 户 的 请 求 立即 失败 ， 并 且 给 
出 友好 的 错误 信息 ， 这 种 情况 是 糟糕 的 。 但 是 ， 如 果 用 户 根本 没有 得 到 任何 的 响应 ， 而 只 
能 无 限 地 等 待 下 去 ， 那 么 情况 就 更 糟糕 了 。 遇 到 这 种 情况 ， 用 户 常见 的 反应 就 是 尝试 刷新 
网 页 。 大 多 数 时 候 ， 这 其 实 并 没有 什么 助 益 ， 只 会 启动 男 外 一 个 请 求 ， 进 一 步 加 重 系 统 的 
负担 。 一 个 慢 服务 会 导致 进一步 的 级 联 ， 从 而 让 整个 系统 陷入 停顿 。 使 用 慢 服务 的 其 他 所 
有 服务 会 突然 变 得 非常 缓慢 ， 而 且 这 种 情况 会 递归 级 联 。Hystrix 试图 屏蔽 这 种 破坏 性 的 依 
赖 关系 并 停止 故障 的 级 联 。 


8.2.1 使 用 Hystrix 的 第 一 步 


本 书 介 绍 Hystrix 有 多 重 原因 。 首 先 ， 它 是 基于 RxJava 构建 的 ， 这 样 ， 它 就 成 为 了 现实 
生活 中 Reactive Extensions 的 一 个 绝 佳 的 实际 样 例 。 其 次 ， 我 们 可 以 调用 Hystrix 命令 并 得 到 
0bservablte 类 型 的 返回 值 。 最 后 ， 也 是 最 重要 的 ，Hystrix 支持 非 阻 塞 的 命令 (参见 8.2.2 节 )。 
但 是 在 继续 讲解 之 前 ， 先 看 一 下 如 何 将 Hystrix 用 到 最 简单 的 阻塞 式 场景 中 。 根 据 经 验 ， 
要 将 Hystrix 用 在 执行 脱离 了 进程 或 机 器 的 地 方 。 发 起 网 络 调用 (也 包括 访问 WO) 会 显著 
增加 失败 的 风险 : 风险 可 能 包括 难以 预料 的 延迟 、 网 络 分 区 或 数据 包 丢 失 。 在 识别 出 这 样 








































































































236 | 第 8 章 


有 潜在 风险 的 代码 块 之 后 ， 使 用 HystrixCommand 对 其 进行 包装 。 


import org.apache.commons.io.IOUtils; 
import com.netflix.hystrix.HystrixCommand; 
import com.netflix.hystrix.HystrixCommandGroupKey; 


class BlockingCmd extends HystrixCommand<String> { 


public BlockingCmd() { 
super(HystrixCommandGroupKey .Factory.asKey("SomeGroup")); 


} 


@Override 
protected String run() throws IOException { 
final URL url = new URL("http://www.example.com"); 
try (InputStream input = url.openStream()) { 
return IOUtils.toString(input, StandardCharsets.UTF._8); 
} 


} 


样 例 将 可 能 会 失败 的 阻塞 式 代码 封装 到 一 个 run() 方法 中 。 这 个 方法 的 T 类 型 是 通过 
HystrixCommand<T> 泛 型 定义 的 。 如 果 想 要 参数 化 操作 (比如 使 用 不 同 URL) ， 那 么 它 必须 
要 通过 构造 器 传递 进来 。HystrixCommand 是 命令 (Command) 设计 模式 的 一 种 实现 ， 这 个 
模式 是 在 Erich Gamma 等 人 编写 的 经 典 《设计 模式 : 可 复 用 面向 对 象 软件 的 基础 》 中 定 
义 的 。 

有 了 HystrixCommand 实例 之 后 ， 必 须要 以 某 种 方式 执行 它 。 这 里 有 两 种 执行 方式 : 按照 命 
令 的 方式 执行 ， 或 者 获取 先 于 Java 8 提供 的 一 个 Future 实例 。 不 过 这 两 种 方式 都 没什么 吸 
引力 。 


String string 
Future<String> future 





new BlockingCmd().execute(); 
new BlockingCmd().queue(); 


execute() 会 通过 一 个 安全 网 ， 间 接 调 用 run() 方法 ， 这 个 安全 网 包括 了 超时 、 高 级 的 错误 
处 理 等 ，8.2.3 节 将 介绍 更 多 相关 内 容 。 这 个 方法 会 一 直 阻 寨 ， 只 有 底层 的 run() 完成 或 抛 
出 异常 的 时 候 ， 它 才 会 返回 。 在 这 种 情况 下 ， 异 常会 传递 给 调用 者 。 而 queue() 是 非 阻塞 
的 ,但 是 它 会 返回 Future<T>。 旧 的 Future 接口 并 不 具备 真正 的 反应 性 ， 因 此 本 书 不 会 过 
多 关注 execute() 和 queue()。 


注意 ， 在 这 里 每 次 都 会 创建 新 的 BlockingCcmd， 我 们 不 能 跨 多 次 执行 重用 命 
令 实 例 。HystrixCommand 命令 应 该 是 在 执行 之 前 直接 创建 的 ， 不 能 进 和 
用 。 在 实践 中 ， 通 常会 在 邓 
也 值得 怀疑 了 。 
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| 建 时 对 命令 进行 参数 化 ， 这 样 ， 实 例 的 可 重用 性 
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Hystrix 支持 将 0bservable 作为 一 等 公民 ,，“ 可 以 将 命令 的 结果 返回 为 流 。 




















注 2: 事实 上 ，execute() 是 通过 queue() 实现 的 ， 而 queue() 又 是 通过 to0bservabte() 实现 的 。 
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new BlockingCmd().observe(); 
new BlockingCmd().toObservable(); 


Observable<String> eager 
Observable<String> lazy 


observe() 和 toObservable() 在 语义 上 的 差异 非常 重要 。to0bservabtLe() 会 将 一 个 命令 转 
换 成 延迟 执行 的 cold 类 型 的 observable， 换 言 之 ， 在 实际 有 人 订阅 该 0bservable 之 前 不 
会 执行 这 个 命令 。 另 外 ， 这 个 0bservable 不 会 进行 缓存 ， 即 每 次 subscribe() 都 会 触发 命 
令 的 执行 。 与 之 不 同 ，observe() 会 以 异步 的 方式 直接 执行 该 命令 ， 返 回 一 个 hot 类 型 且 支 
持 缓存 的 0bservabte。 正 如 4.3 节 介 绍 的 ， 延 迟 执行 的 0bservabte 非常 便利 ， 比 如 可 以 在 
任何 时 间 点 创建 它们 ， 但 是 不 进行 订阅 。 这 样 ， 就 能 避免 产生 网 络 调用 这 样 的 副作用 ， 还 
可 以 非常 有 效 地 进行 批量 请 求 。 但 是 ，cold 类 型 的 observabte 也 有 一 个 风险 : 如 果 有 多 个 
订阅 者 ， 那 么 将 会 被 调用 多 次 。 在 这 种 情况 下 ，cache() 操作 符 就 能 发 挥 作 用 了 。 延 迟 执 
行 一 般 能 够 实现 最 高 效率 的 并 发 ， 所 以 应 该 优先 使 用 toobservable()， 而 不 是 observe()， 
除非 有 充分 的 理由 立即 调用 某 条 命令 。 


有 了 Observable 之 后 ， 我 们 就 可 以 使 用 各 种 操作 符 了 ， 例 如 对 失败 的 命令 使 用 retry()。 


Observable<String> retried = new BlockingCmd() 
.toObservable() 
.doOnError(ex -> log.warn("Error ", ex)) 
.retryWhen(ex -> ex.delay(500, MILLISECONDS)) 
.timeout(3, SECONDS); 


上 述 管道 会 调用 一 条 命令 ， 如 果 失 败 ， 样 例会 在 500 训 秒 之 后 重 试 。 但 是 ， 重 试 可 能 会 耗 
费 3 秒 的 上 时间， 如 果 超 出 了 这 个 时 间 ， 就 会 抛 出 TimeoutException (参见 7.1.3 节 )。 接 下 
来 将 介绍 Hystrix 内 置 的 超时 功能 如 何 发 挥 作用 。 























8.2.2 ”使 用 HystrixobservabLeCommand 的 非 阻塞 命令 


如 果 在 设计 应 用 程序 的 时 候 就 使 用 到 了 RxJava， 那 么 很 可 能 已 经 对 第 三 方 服 务 或 未 知 
库 的 调用 建 模 为 Obbservable。 共 本 的 HystrixCommand 只 支持 阻塞 式 的 代码 。 但 是 ， 如 果 
与 外 部 世界 的 交互 已 经 是 0bservable， 而 且 还 想 使 用 Hystrix 实现 进一步 的 保护 ， 那 么 
Hystrix0bservableCommand 就 是 合适 的 选择 。 























public class CitiesCmd extends HystrixObservableCommand<Cities> { 


private final MeetupApi api; 
private final double lat; 
private final double lon; 


protected CitiesCmd(MeetupApi api, double lat, double lon) { 
super(HystrixCommandGroupKey .Factory.asKey("Meetup")); 
this.api = api; 


this.lat = lat; 
this. lon = Lon; 
} 
@Override 


protected Observable<Cities> construct() { 
return api.listCities(lat, lon); 











MeetupApi 在 8.1.2 节 中 介绍 过 ， 它 可 以 返回 0bservabtLe<Cities>。Hystrix 透明 地 包装 了 这 
个 0bservable， 从 而 添加 了 容错 处 理 的 特性 ， 稍 后 会 对 其 进行 介绍 。 相 对 于 BlockingCmd， 
CitiesCmd 更 加 实用 ， 因 为 在 它 的 构造 器 中 接收 了 一 些 参数 。 在 单元 测试 中 ， 可 以 传 入 一 
个 MeetupApi 的 存根 实例 ， 以 验证 命令 行为 。 


与 HystrixCommand 相 比 ，Hystrix0bservabLeCommand 的 优势 在 于 其 操作 不 需要 线程 池 。 
HystrixCommand 始终 在 一 个 有 界 的 线程 地 中 执行 ， 而 0bservable 命令 不 需要 任何 额外 的 线 
程 。 当 然 ，construct() (注意 这 里 不 再 是 run() 了 ) 返回 的 0bservable 依然 可 以 使 用 某 些 
依赖 于 底层 实现 的 线程 。 


现在 ， 知 道 了 如 何在 Hystrix 中 创建 命令 ， 以 及 它们 如 何 适应 RxJava 生态 系统 ， 接 下 来 介 
绍 一 下 Hystrix 都 提供 了 哪些 实际 的 功能 。 


8.2.3 ” 舱 壁 模式 和 快速 失败 
舱 壁 (bulkhead) 是 横 跨 轮船 船体 的 大 墙 ， 它 们 会 形成 水 密 舱 。 如 果 出 现 漏 水 ， 舱 壁 会 将 
水 隔离 在 一 个 水 密 舱 中 ， 防 止 轮船 沉没 。 相 同 的 工程 理念 可 以 应 用 到 分 布 式 系统 。 如 果 应 
用 程序 中 的 一 个 组 件 出 现 失败 ， 那 么 它 应 该 被 隔离 起 来 。 这 样 即便 某 个 组 件 出 现 了 故障 ， 
整个 系统 也 能 正常 运行 。 

另外 一 个 可 以 很 好 地 应 用 于 软件 领域 的 工程 模式 是 断路 器 (circuit breaker) 。 断 路 器 的 责任 
是 中 断 电流 ， 避 免 各 种 设备 过 载 甚至 着 火 。 在 危险 解除 之 后 ， 断 路 器 可 以 复位 (以 人 工 或 
自动 化 的 方式 )。 但 是 ， 这 是 否 会 导致 电灯 、 加 热 器 或 者 (最 糟糕 的 情况 下 ) 路 由 器 出 现 
断 点 呢 ? 不 一 定 。 其 他 电路 网 络 可 能 会 收 到 其 他 断路 器 保护 ， 因 此 它们 依然 能 够 运行 。 最 
重要 的 是 ， 你 的 房子 没有 着 火 。 

Hystrix 在 系统 集成 领域 实现 了 这 两 种 模式 。 每 条 命令 都 有 超时 时 间 (默认 为 1 秒 ) 和 并 发 
限制 (默认 情况 下 ， 给 定 组 只 能 有 10 条 并 发 命令 )。 这 些 严格 的 限制 确保 了 命令 不 会 消耗 
太 多 的 资产， 比如 线程 和 内 存 。 同 时 ， 使 用 超时 功能 能 够 确保 不 会 引入 过 多 的 延迟 。 我 们 
可 以 将 这 种 行为 与 轮船 上 的 舱 壁 进行 对 比 ， 如 果 某 一 个 依赖 开始 出 现 失败 〈 注 意 ， 过 高 的 
延迟 和 失败 几乎 无 法 区 分 )， 这 个 问题 将 不 再 影响 整个 系统 。 超 时 和 有 限 的 并 发 能 够 明显 
减少 阻塞 在 外 部 系统 的 线程 数量 。 


断路 器 则 更 加 聪明 。 假 设 ， 某 个 以 前 100 毫秒 就 能 响应 的 依赖 ， 现 在 几乎 要 等 待 1 秒 才 会 
产生 超时 。 如 果 对 这 个 行为 不 正常 的 依赖 的 调用 是 整个 处 理 流程 的 一 部 分 ， 那 么 现在 几乎 
每 个 事务 都 会 比 原来 慢 一 秒 。 如 果 没 有 Hystrix， 这 个 延迟 可 能 会 大 得 更 多 ， 不 过 使 用 纯粹 
的 RxJava 也 可 以 实现 超时 功能 。Hystrix 能 做 的 并 不 局 限于 此 。 如 果 它 发 现 特定 的 命令 在 
给 定 的 时 间 窗 口 (默认 为 10 秒 ) 频繁 地 (默认 为 全 部 调用 的 50%) 失败 〈 出 现 异 常 或 超 
时 )， 那 么 它 就 会 打开 一 个 回路 。 接 下 来 发 生 的 事情 就 会 很 有 意思 了 ，Hystrix 将 不 再 调用 
出 现 故 障 的 命令 。 相 反 ， 它 会 立即 抛 出 一 个 异常 ， 快 速 失败 。 

接 下 来 实际 看 看 Hystrix。 首 先 ， 使 用 Mockito 模拟 (mock-up) MeetupApt， 这 样 ， 它 会 始 
终 由 于 一 些 不 可 接受 的 延迟 而 失败 ， 如 下 所 示 。 


import static org.mockito.BDDMockito.given; 
import static org.mockito.Matchers.anyDouble; 
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import static org.mockito.Mockito.mock; 


MeetupApi api = mock(MeetupApi .class); 
given(api. listCities(anyDouble(), anyDouble())).willReturn( 
Observable 
.<Cities>error(new RuntimeException("Broken")) 
.doOnSubscribe(() -> log.debug("Invoking")) 
.delay(2, SECONDS) 
); 


默认 的 超时 时 间 是 1 秒 ， 所 以 实际 上 我 们 永远 都 不 会 看 到 “Broken” 异 常 ， 因 为 超时 会 首 
先生 效 。 现 在 ， 我 们 想 要 多 次 并 发 调用 MeetupApi 并 查看 Hystrix 的 行为 。 


Observable 
.interval(50, MILLISECONDS) 
.do0nNext(x -> log.debug("Requesting")) 
.flatMap(x -> 
new CitiesCmd(api, 52.229841, 21.011736) 
.toObservable() 
.ONErrorResumeNext(ex -> Observable.empty()), 











5) 
使 用 interval() 操作 符 ， 每 50 毫秒 发 布 一 个 事件 。 每 当 遇 到 这 种 事件 ， 样 例 都 会 触发 
CitiesCmd 命令 并 将 异常 隐藏 掉 。 注 意 ， 在 实际 的 项 目 中 ， 我 们 至 少 应 该 使 用 doOnError() 
回调 来 记录 异常 信息 。Hystrix 每 隔 50 毫秒 就 会 调用 命令 ， 并 在 1 秒 之 后 得 到 超时 的 通知 。 
这 个 命令 实际 执行 得 更 慢 ， 但 是 Hystrix 会 提前 中 断 它 。 我 们 进行 订阅 并 运行 这 个 程序 的 
时 候 ， 会 发 现 CitiesCmd 被 调用 几 次 ,但 随后 就 突然 停止 。 尽 管 “Requesting” 消 息 依然 
每 隔 50 毫秒 出 现 ， 但 是 命令 不 会 再 被 调用 了 。 


通过 一 些 启发 式 的 算法 ，Hystrix 判断 CitiesCmd 已 经 出 现 了 问题 ， 所 以 不 再 调用 它 。 相 
反 ， 当 我 们 堂 试 调用 这 个 命令 ， 产 生 的 Observable 会 立即 失败 并 伴 有 一 个 异常 。 这 里 ， 断 
路 器 介入 并 导致 对 命令 的 调用 快速 失败 。 命 令 根本 就 不 会 被 调用 ， 因 为 Hystrix 认为 它 会 
一 直 失 败 ， 没 有 调用 的 必要 。 失 败 率 超过 50% 的 时 候 ， 断 路 器 就 会 打开 ， 调 用 命令 的 后 续 
尝试 都 会 瞬间 失败 。 在 失败 时 ，Hystrix 会 假定 出 现 异 常 或 超时 。 


断路 器 有 双重 优点 。 从 调用 命令 的 应 用 程序 的 角度 ， 不 管 怎样 它 最 终 都 会 失败 ， 但 是 能 够 
更 快 地 得 到 响应 ， 这 会 带 来 更 好 的 用 户 体验 。 更 有 意思 的 是 在 服务 器 端 ， 或 者 是 说 命令 中 
请 求 要 访问 的 目标 。 如 果 命 令 持 续 失 败 或 者 超时 ， 那 么 这 可 能 是 依赖 〈 另 外 的 服务 、 数 据 
库 ) 遇 到 困难 的 一 个 信号 。 这 可 能 是 重启 、 流 量 峰 值 或 者 长 时 间 的 GC 停顿 导致 的 。 我 们 
通过 断路 器 切断 这 个 命令 ， 从 而 给 了 系统 哈 息 的 空间 。 负 和 载 峰值 结束 或 内 部 任务 队列 清空 
时 ， 系 统 可 能 会 重新 恢复 响应 并 健康 状态 。 这 样 ， 能 够 防止 系统 对 自己 发 起 分 布 式 拒绝 服 
务 攻击 (Distributed Denial of Service，DDoS ) 。 


那么 ，Hystrix 是 怎样 识别 出 下 游 依赖 重新 恢复 健康 状态 并 将 断路 器 关闭 的 呢 ? 幸而 ， 这 个 
过 程 是 自动 完成 的 。 在 前 面 的 样 例 中 ， 我 们 在 某 个 时 间 点 看 不 到 Invoking 日 志 信息 了 。 这 
意味 着 断路 器 已 经 打开 ， 命 令 不 再 执行 了 。 但 事实 并 非 完 全 如 此 。 每 隔 一 段 时 间 (默认 是 
每 5 秒 )，Hystrix 就 会 允许 一 个 请 求 通过 并 执行 命令 ， 以 此 来 检查 此 时 是 否 已 经 恢复 健康 
状态 。 与 此 同时 ， 其 他 客户 端 依然 会 快速 失败 。 如 果 这 个 请 求 成 功 ，Hystrix 就 会 假定 命令 
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已 经 恢复 健康 状态 ， 并 将 断路 器 关闭 ， 否 则 ， 断 路 器 会 依然 处 于 打开 状态 。 


这 种 特性 叫 作 自 愈 (self-healing)， 在 计算 机 系统 中 是 一 个 重要 的 概念 。Hystrix 能 够 在 两 
0 通过 临时 关闭 出 现 问 题 的 命令 ， 让 下 游 的 依赖 恢复 健康 。 在 它们 恢复 之 

后 ， 系 统 将 回归 正常 的 操作 流程 。 如 果 没 有 这 种 机 制 ， 即 便 一 个 很 小 的 故障 都 可 能 导致 级 
联 失败 ， 为 了 恢复 各 个 组 件 的 稳定 性 ， 我 们 可 能 还 需要 手动 重 局 。 


8.2.4 批 处理 和 合并 命令 
Hystrix 最 高 级 的 特性 之 一 就 是 请 求 的 批量 处 理 。 假 设 处 理 一 个 上 游 请 求 的 过 程 中 ， 需 要 疝 
下 游 发 起 多 次 小 规模 的 请 求 。 例 如 ， 我 们 想 要 展现 一 个 图 书 的 列表 ， 每 本 书 都 需要 请 求 一 
个 外 部 系统 来 获取 它 的 评分 。 

Observable<Book> allBooks() { /* ... */ } 

Observable<Rating> fetchRating(Book book) { /* ... */ } 


allBooks() 方法 会 返回 我 们 想 要 处 理 的 Book 流 ，fetchRating() 则 会 为 每 本 书 Book 返回 一 
个 评分 Rating。 原 始 实现 可 能 会 遍历 所 有 的 图 书 并 依次 检索 其 Rating。 幸 而 ， 使 用 RxJava 
异步 运行 子 任务 非常 容易 。 
Observable<Rating> ratings = allBooks() 
.flatMap(this: :fetchRating); 


图 8-1 和 图 8-2 对 比 了 序列 化 调用 fetchRatings() 与 使 用 flatMap() 的 差异 。 在 这 几 个 阶 
段 中 ，send 指 的 是 传输 请 求 ，proc 指 的 是 服务 器 端 处 理 ， 而 recv 指 的 是 传输 响应 。 图 8-1 
展现 了 序列 化 获取 数据 的 过 程 。 


main 一 一 《send XprocX ec X send XproX ec 从 send XprocX ec 广 




























































































8-1 
图 8-2 展示 了 使 用 flatMap() 获取 数据 的 场景 。 








Rl 一 一 send 人 procX rec 2 
R22 一 一 人 (send 人 procX rec 广 
R3 一 一 《send 人 procX rec 2 
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这 运行 得 非常 好 ， 通 常 也 能 看 到 令 人 满意 的 性 能 。 所 有 的 fetchRatings() 都 是 并 发 执行 
的 ， 从 而 极 大 地 改善 了 延迟 。 但 是 ， 如 果 每 次 调用 fetchRatings() 都 会 带 来 固定 量 的 网 络 
延迟 ， 那 么 为 几 十 本 图 书 而 调用 它 就 非常 浪费 了 。 如 果 为 所 有 图 书 只 发 送 一 个 批量 请 求 ， 
并 在 一 个 响应 中 得 到 所 有 图 书 的 评分 信息 ， 那 么 以 下 这 种 方式 看 上 去 会 更 有 效 ， 如 图 8-3 
所 示 。 
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Rx1 一 一 (send6) 人 procG) 人 TecwG) 六 
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注意 ， 这 种 情况 下 所 有 的 阶段 (发 送 、 处 理 和 接收 ) 在 一 定 程度 上 都 会 稍 慢 一 些 。 所 有 这 
些 阶段 都 要 传输 或 处 理 更 多 的 数据 ， 这 是 可 以 理解 的 。 因 此 ， 相 对 于 发 送 多 个 小 规模 的 请 
求 ， 总 的 延迟 实际 上 会 更 高 。 这 种 改善 值得 怀疑 ， 但 是 我 们 必须 从 更 高 的 角度 来 看 问题 。 
尽管 单个 请 求 的 延迟 会 增加 ， 但 是 系统 的 否 吐 量 可 能 会 得 到 大 幅 提 升 。 我 们 能 够 处 理 的 并 
发 连接 数 、 网 络 否 吐 以 及 JVM 线程 都 是 有 限 且 稀缺 的 资源 。 如 果 请 求 的 依赖 否 吐 量 有 限 ， 
那么 使 用 并 发 来 实现 的 几 个 事务 就 有 可 能 使 其 饱和 。 私 自 使 用 flatMap() 能 够 改善 单个 请 
求 的 延迟 ， 但 是 这 样 会 使 资源 饱和 ， 从 而 降低 其 他 请 求 的 性 能 。 因 此 ， 我 们 希望 辆 牲 一 点 
延迟 ， 避 免 对 下 游 依赖 产生 太 大 的 负载 ， 以 获取 更 好 的 吞吐 量 。 最 终 ， 延 迟 实际 上 也 能 得 
到 改善 : 请 求 在 共享 资源 方面 更 加 公平 ， 因 此 延迟 也 更 具 可 预测 性 。 

那么 ， 该 如 何 实现 批 处 理 呢 ? Hystrix 能 够 感知 执行 的 每 个 命令 。 要 同时 执行 两 条 类 似 的 
命令 〈 比 如 获取 两 个 Rating) 时 ， 它 能 够 将 这 两 条 命令 合并 为 一 个 更 大 的 批 处 理 命令 。 这 
个 批 处 理 命令 会 被 调用 ， 而 且 批量 响应 到 达 时 ， 这 些 响应 数据 会 映射 回 原始 的 单个 请 求 。 
首先 ， 我们 需要 一 个 批 处 理 命令 的 实现 ， 它 能 够 一 次 性 检索 多 个 Rating 信息 ， 如 下 所 示 。 


class FetchManyRatings extends HystrixObservableCommand<Rating> { 


































































































private final Collection<Book> books; 


protected FetchManyRatings(Collection<Book> books) { 
super(HystrixCommandGroupKey .Factory.asKey("Books")); 
this.books = books; 


} 


@Override 
protected Observable<Rating> construct() { 
return fetchManyRatings(books); 


} 
} 


fetchManyRatings() 方法 接收 books 作为 参数 ， 并 且 发 布 多 个 Rating 实例 。 在 内 部 ， 它 可 
以 通过 一 条 HTTP 请 求 ， 获 取 多 个 评分 信息 ， 这 与 fetchRating(book) 截然 不 同 ， 后 者 永 
远 只 能 获取 一 个 评分 信息 。 请 求 多 个 Rating 显然 会 更 慢 ， 但 是 肯定 比 序列 化 获取 Rating 
快 一 些 。 但 是 ， 我 们 并 不 想 手 动 管理 批 处 理 中 的 多 个 请 求 ， 然 后 再 拆 解 批 处 理 的 响应 。 如 
果 只 处 理 一 个 事务 ， 这 可 能 还 简单 一 些 ， 但 是 如 果 有 多 个 并 发 客户 端 ， 每 个 客户 端 都 请 求 
Rating， 又 该 如 何 处 理 呢 ? 来自 两 个 浏览 器 的 独立 请 求 访问 服务 器 的 时 候 ， 我 们 依然 想 对 
这 两 个 请 求 进行 批 处 理 ， 并 且 只 对 下 游 发 送 一 次 调用 。 这 就 需要 线程 间 的 同步 ， 以 及 所 有 
请 求 的 全 局 注册 表 。 假 设 某 个 线程 试图 调用 给 定 的 命令 ， 而 另外 一 个 线程 在 几 毫 秒 之 后 调 
用 了 相同 的 命令 (参数 不 同 )。 我 们 想 要 在 第 一 个 请 求 尝试 启动 命令 之 后 等 待 一 会 儿 ， 以 
防 稍 后 有 另外 的 线程 尝试 调用 相同 的 命令 。 如 果 是 这 样 ， 我 们 将 捕获 这 两 个 请 求 ， 把 它们 
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合并 在 一 起 ， 只 发 送 一 次 批 处 理 请 求 ， 然 后 将 批 处 理 响 应 映射 回 各 个 独立 请 求 。 这 正 是 
Hystrix 在 样 例 的 帮助 下 做 的 事情 。 
public class FetchRatingsCollapser 


extends HystrixObservableCollapser<Book, Rating, 
Rating, Book> { 











private final Book book; 


public FetchRatingsCollapser(Book book) { 
// 后 面 进行 阐述 














} 


public Book getRequestArgument() { 
return book; 


} 


protected HystrixObservableCommand<Rating> createCommand( 
Collection<HystrixCollapser.CollapsedRequest<Rating, Book>> requests) { 
// 后 面 进行 益 述 














} 


protected void onMissingResponse( 
HystrixCollapser.CollapsedRequest<Rating, Book> r) 
{ 


r.setException(new RuntimeException("Not found for: " 
+ Fr.getArgument())); 


} 


protected Func1<Book，Book> getRequestArgumentKeySeLector() { 
return x -> x; 


} 


protected Funci<Rating, Rating> getBatchReturnTypeToResponseTypeMapper() { 
return x -> x; 


} 


protected Funci<Rating, Book> getBatchReturnTypeKeySelector() { 
return Rating::getBook; 


} 
} 


这 里 有 很 多 代码 ， 接 下 来 逐步 进行 分 析 。 我 们 想 要 检索 指定 Book 的 Rating， 于 是 创 如 
一 个 FetchRatingsCollapser 实例 ， 如 下 所 示 。 





[es 
一 | 


Observable<Rating> ratingObservable = 
new FetchRatingsCollapser(book).toObservable(); 


得 益 于 Hystrix0bservableCollapser， 客 户 端 代码 完全 不 知道 正在 发 生 的 批 处 理 和 命令 合 
并 。 从 外 部 看 ， 使 用 方式 仿佛 依然 是 为 一 个 Book 获取 Rating。 但 是 在 内 部 ， 一 些 比较 有 
意思 的 细节 使 得 我 们 可 以 进行 批 处 理 。 首 先 ， 在 构造 器 中 ， 除 了 存储 该 请 求 的 Book， 还 配 
置 了 请 求 的 合并 。 


下 
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public FetchRatingsCollapser(Book book) { 
super(withCollapserKey(HystrixCollapserKey .Factory.asKey("Books")) 
.andCollapserPropertiesDefaults(HystrixCollapserProperties.Setter() 
.withTimerDelayInMilliseconds(20) 
.withMaxRequestsInBatch(50) 


) 
.andScope(Scope.GLOBAL) ); 
this .book = book; 


withTimerDelayInMilliseconds() 配置 的 20 毫秒 是 合并 发 生 的 时 间 窗 口 的 长 度 (默认 为 
10 毫秒 )。 第 一 个 请 求 发 生 后 ， 在 它 真 正 被 调用 之 前 会 经 过 20 毫秒 的 延迟 。 这 段 时 间 内 ， 
Hystrix 会 等 待 其 他 请 求 抵 达 ， 这 些 请 求 可 能 由 其 他 线程 发 起 。Hystrix 会 试探 性 地 延迟 第 
一 个 请 求 ， 以 查看 是 否 有 同 种 类 型 的 命令 抵达 。 当 时 间 耗 尽 或 者 排队 的 请 求 已 经 达到 了 50 
个 (withMaxRequestsInBatch(59) 参数 设置 的 )， 大 门将 会 关闭 。 此 时 ， 假定 Hystrix 将 在 
一 个 批 次 中 调用 所 有 排队 的 命令 。 但 是 ，Hystrix 并 不 会 神奇 地 将 命令 批量 处 理 为 一 个 ， 我 
们 必须 指导 它 实现 这 一 点 。 以 下 代码 段 展示 了 这 个 功能 的 实现 。 
protected HystrixObservableCommand<Rating> 
createCommand( 
Collection<HystrixCollapser .CoLLapsedRequest<Rating ， 
Book>> requests) { 
List<Book> books = requests.stream() 
.map(c -> c.getArgument()) 


.Collect(toList()); 
return new FetchManyRatings(books); 

















} 
createCommand() 方法 负责 将 多 个 单独 的 请 求 转换 为 一 个 批 处 理 命令 。 它 会 20 毫秒 时 
间 段 内 收集 到 的 所 有 请 求 ， ne 批 处 理 的 命令 。 在 这 个 场景 中 ， 构 

















建 一 个 FetchManyRatings 命令 的 实例 ， 它 会 为 所 有 Book 获取 Rating 数据 。 随后 会 
触发 批 处 理 命令 并 订阅 所 有 了 响应。 注意 ， | 允许 返回 多 个 值 ， 而 
这 就 是 我 们 想 要 实现 的 功能 。 


FetchManyRatings 开始 出 现 值 的 时 候 ， 必 须要 以 某 种 方式 将 Rating 实例 与 独立 的 请 求 匹 
配 起 来 。 此 时 需要 注意 ， 可 能 会 有 多 个 独立 的 线程 和 事务 ， 每 个 线程 和 事务 都 在 等 待 一 个 
Rating 结果 。 批 处 时 的 响应 路 由 和 分 发 至 单独 的 请 求 ， 会 会 通过 如 下 的 方法 或 多 或 少 地 自动 
口 ee 
个 方法 会 将 单个 请 求 的 参数 〈Book) 映射 为 一 个 key， 随 后 使 用 这 个 key 映射 批 处 理 
Re 这 个 场景 只 是 使 用 了 相同 的 Book 实例 ， 因 此 会 进行 x -> x 恒 等 转换 。 


口 getBatchReturnTypeToResponseTypeMapper() 
这 个 方法 会 将 批 处 理 响应 的 每 个 条 目 映 射 为 单个 响应 。 同 样 ， 在 这 个 场景 中 ,使 用 x 
-> x 恒 等 转换 就 足够 了 。 

口 getBatchReturnTypeKeySelector() 
这 个 方法 可 以 让 Hystrix 分 辩 特 定 的 响应 〈Rating) 是 应 对 哪个 请 求 key (Book) 的 。 简 单 起 
见 ， 批 处 理 响 应 返回 的 每 个 Rating 都 有 一 个 getBook() 方法 ， 用 来 指定 与 它 相关 的 Book。 










































































这 些 方法 (尤其 是 最 后 一 个 ，getBatchReturnTypeKeySelector()) 就 绪 之 后 ，Hystrix 会 根 
据 请 求 的 key (Book) 准备 一 个 映射 ,一旦 新 的 Rating 从 批 处 理 响 应 中 出 现 ， 它 就 能 自动 
地 将 响应 与 请 求 进行 匹配 。 

让 批 处 理 开始 运行 ， 我 们 需要 进行 很 多 准备 工作 ,但 是 很 快 就 能 得 到 回报 。 多 个 客户 端 访 
问 相 同 的 下 游 依赖 例如， 缓存 服 务 器 ) 时 ， 可 以 将 多 个 请 求 收集 为 一 个 。 这 会 明显 减少 
带宽 的 成 本 。 当 依赖 成 为 产 贷 ， 而 否 吐 量 又 有 限 的 时 候 ， 合 并 请 求 将 极 大 地 减少 依赖 的 负 
载 。 但 是 , 批 处 理 在 客户 端 引入 了 额外 的 延迟 。 按 照 默 认 配 置 10 毫秒 (withTimerDelayInM 
illiseconds(10)), 在 高 负载 的 情况 下 ,每 个 请 求 平均 会 延迟 5 毫秒 。 实 际 的 延迟 取决 于 当 
前 的 请 求 是 刚刚 启动 一 个 计时 器 ， 还 是 出 现在 这 个 批 次 即将 结束 之 前 。 

需要 注意 ， 在 低 负载 的 时 候 ， 批 处 理 并 没有 太 大 的 价值 。 如 果 在 每 个 批 次 中 ， 请 求 的 数量 
很 少 超过 一 个 ， 那 么 只 是 给 每 个 请 求 都 添加 了 额外 的 10 毫秒 延迟 而 已 。 这 是 Hystrix 毫 无 
意义 地 等 待 其 他 请 求 的 时 间 。 因 此 ， 对 批 次 的 调 优 是 非常 重要 的 。 如 果 你 的 定时 器 延迟 是 
10 毫秒 ， 那 么 上 只 有 当 每 秒 至 少 有 1000 个 请 求 的 时 候 ， 批 处 理 才 有 意义 。 否 则 ， 很 少 会 出 
现 多 个 请 求 形成 一 个 批 处 理 的 情况 。 

调 优 withTimerDelayInMilliseconds 

为 了 将 更 多 的 请 求 放 到 一 个 批 次 中 ， 我 们 会 忍 不 住 设置 较 长 的 延迟 。 像 100 
毫秒 黄 至 1 秒 这 样 的 值 都 是 可 以 的 ， 但 是 这 种 情况 在 离线 系统 中 效果 会 最 

好 ， 因 为 这 会 产生 大 量 的 流量 ， 而 且 延 迟 并 不 是 什么 问题 。 







































































在 高 负载 的 情况 下 ， 批 处 理 是 运行 得 最 好 的 特性 。 因 此 ，Hystrix 提供 了 非常 全 面 的 监控 机 
制 ， 帮 助 我 们 理解 整体 的 系统 性 能 。 


8.2.5 ”监控 和 仪表 盘 
为 了 正常 运行 ， 随 着 时 间 的 推移 ，Hystrix 必须 在 内 部 为 每 个 命令 收集 大 量 的 统计 数据 ， 比 
如 统计 成 功 和 失败 调用 的 数量 以 及 响应 时 间 的 分 布 。 如 果 这 些 宝贵 的 数据 只 能 在 这 个 库 中 
使 用 ， 就 显得 有 些 自私 了 。 但 是 不 必 担 心 : Hystrix 提供 了 多 种 方式 来 使 用 这 些 数据 。 我 们 
可 以 订阅 Hystrix 提供 的 各 种 类 型 的 流 ， 这 些 流 会 发 布 Hystrix 库 中 发 生 的 事件 。 例 如 ， 以 
下 代码 创建 了 一 个 HystrixCommandCompletion 事件 流 ， 每 当 FetchRating 命令 完成 时 ， 这 
个 流 都 会 发 布 事件 。 

import com.netflix.hystrix.metric.HystrixCommandCompletion; 

import com.netflix.hystrix.metric.HystrixCommandCompletionStream; 


















































Observable<HystrixCommandCompletion> stats = 
HystrixCommandCompletionStream 
.getInstance(HystrixCommandKey .Factory.asKey("FetchRating")) 
.Observe(); 


HystrixCommandCompletionstream 是 这 种 流 的 工厂 ， 但 是 还 有 很 多 其 他 的 流 ， 比 如 
HystrixCommandStartStream 和 HystrixCollapserEventStream。 将 这 些 流 幢 入 到 应 用 程序 之 
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后 


那么 





就 能 构建 更 加 复杂 的 监控 系统 了 。 例 如 ， 我 们 想 要 知道 给 定 的 命令 每 秒 失败 的 次 数 ， 
可 以 尝试 如 下 的 代码 。 


import static com.netflix.hystrix.HystrixEventType.FAILURE; 


HystrixCommandCompletionStream 
.getInstance(HystrixCommandKey .Factory.asKey("FetchRating")) 
.observe() 
.filter(e -> e.getEventCounts().getCount(FAILURE) > 0) 
.window(1, TimeUnit.SECONDS) 
.flatMap(Observable: :count) 
.Subscribe(x -> log.info("{} failures/s", x)); 


但 是 ， 基 于 这 些 流 构建 监控 基础 设施 还 需要 一 些 设计 和 相关 工作 。 同 时 ， 我 们 可 能 还 希望 
将 监控 功能 从 实际 的 应 用 中 抽取 出 来 。Hystrix 借助 hystrix-metrics-event-strean 模块 ， 
能 够 将 所 有 聚合 的 指标 通过 HTTP 推送 出 来 。 如 果 应 用 程序 已 经 运行 或 者 使 用 租 入 式 的 
Servlet 容器 ， 那 么 只 需要 给 映射 添加 一 个 内 置 的 HystrixMetricsStreamServLet。 否 则 ， 我 











要 自行 启动 一 个 小 型 的 容器 。 





import 

com.netflix.hystrix.contrib.metrics.eventstreanm. 
HystrixMetricsStreamServlet; 

import org.eclipse.jetty.server.Server; 

import org.eclipse.jetty.servlet.ServletContextHandler; 

import org.eclipse.jetty.servlet.ServletHolder; 

import static org.eclipse.jetty.servlet.ServletContextHandler .NO_SESSIONS; 


7 大 


ServletContextHandler context = new ServLetContextHandLer(NO_SESSIONS ) ; 
HystrixMetricsStreamServlet servlet = new HystrixMetricsStreamServlet(); 
context.addServlet(new ServletHolder(servlet), "/hystrix.stream"); 
Server server = new Server(8080); 

server .setHandler(context); 

server.start(); 





无 论 我 们 是 将 Servlet 映射 到 已 有 容器 ， 还 是 自行 启动 容器 ， 通 过 上 面 的 配置 ， 现 在 就 能 够 
实时 访问 流动 的 Hystrix 统计 信息 了 。 注 意 ， 这 个 连接 并 不 是 简单 的 请 求 一 响应 模式 ， 而 
是 一 个 服务 器 推送 事件 (Server-sent Event，SSE) 流 。 每 秒 都 会 有 一 个 新 的 统计 信息 包 以 
JSON 格式 推送 至 客户 端 。 




















$ curl -v localhost:8080/hystrix.stream 
> GET /hystrix.stream HTTP/1.1 


< HTTP/1.1 200 OK 
< Content-Type: text/event-stream;charset=UTF-8 


ping: 
data: { 


"currentConcurrentExecutionCount": 2， 
"errorCount": 0， 





246 


| 第 8 章 


"errorPercentage": 0， 


"group": "Books", 
"isCircuitBreakerOpen": false, 
"latencyExecute": {/* ... */}, 


"latencyExecute_mean": 0， 


"latencyTotal": {"0":18, "25":80, "50":98, "75":120, "90":138, 
"95":146, "99":159, "99.5":159, "100":167}, 


"latencyTotal_mean": 0， 
"name": "FetchRating", 


"propertyValue_circuitBreakerErrorThresholdPercentage": 50， 


"propertyValue_circuitBreakerSleepWindowInMilliseconds": 5000, 


"propertyValue_executionIsolationSemaphoreMaxConcurrentRequests": 10， 


"propertyValue_executionTimeoutInMilliseconds": 1000， 
"requestCount": 334 


} 


data: { ... 





即便 是 这 个 简单 样 例 ， 我 们 也 能 看 出 它 测量 的 是 哪个 命令 、 延 迟 是 如 何 分 布 的 (从 第 0 个 
到 第 100 个 百 分 位 )、 断 路 器 是 否 处 于 打开 的 状态 ， 以 及 断路 器 的 参数 (错误 病 值 、 超 时 
这 种 连续 的 数据 流 可 以 进一步 被 自 定 义 监控 工具 或 仪表 盘 消 费 。 同 样 ，Hystrix 提供 
了 一 个 非常 健壮 的 仪表 盘 ， 它 几乎 全 部 是 使 用 JavaScript 编写 的 ， 可 以 在 浏览 器 中 运行 。 
这 个 独立 的 应 用 程序 (在 hystrix-dashboard 中 实现 ) 需要 的 只 是 一 个 到 hystrix.stream 


等 ) 。 




















的 URL。 图 8-4 展示 了 一 个 示例 仪表 盘 。 























Success | Short-Circuited | Bad Request 
Rejected | Failure | Error % 
FetchRating 
289 13.0 % 
0 0 
31 


Host: 33.5/s 
Cluster: 33.5/s 
Circuit Closed 


Hosts 1 90th 147ms 
Median 98ms 99th 1001ms 
Mean 128ms 99.5th 1001ms 








图 8-4 
每 条 命令 都 有 这 样 的 一 个 详细 图 表 ， 展 示 了 一 些 重 要 的 遥测 指标 细节 ， 包 括 以 下 部 分 。 


行 过 的 命令 ,按照 成 功 的 〈289) .超时 的 〈14) .失败 的 (31) .短路 的 〈0) 等 进行 分 组 。 
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。 延迟 的 百 分 位 (可 以 看 到 90% 的 请 求 耗 时 不 超过 147 毫秒 ) ， 在 图 表 中 展现 了 短期 的 请 
求 历 史 。 
源 路 器 状态 以 及 整体 吞吐 量 。 
如 果 使 用 阻塞 式 HystrtxCommand， 还 会 看 到 线程 池 状 态 。 


仪表 盘 还 能 够 展现 通过 Turbine 聚集 的 其 他 服务 器 的 流 。 这 就 是 我 们 会 看 到 主机 数量 和 集 
群 吞 吐 量 的 原因 ， 当 然 这 里 的 流 是 来 自 一 台 机 器 的 。Hystrix 仪表 盘 非 常 有 用 ， 因 为 它 能 够 
以 接近 实时 的 速度 快速 展现 多 条 命令 的 状态 。 它 还 进行 了 颜色 的 区 分 ， 如 果 有 些 命令 开始 
失败 ， 它 们 对 应 的 图 表 就 会 变 成 红色 。 
在 分 布 式 系统 中 ，Hystrix 是 一 个 非常 有 用 的 工具 ， 因 为 在 这 种 环境 中 ， 失 败 是 难以 避 
免 的。 命令 模式 允许 封装 和 隔离 错误 域 。 对 于 需要 更 好 的 错误 处 理 的 反应 式 应 用 程序 ， 
Hystrix 与 RxJava 的 良好 集成 是 一 个 不 错 的 选择 。 


8.3 ”查询 NoSQL 数 据 库 


目前 ， 典 型 应 用 程序 的 数据 高 延迟 主要 有 两 个 根源 : 网 络 调用 (大 多 数 是 HTTP) 和 数据 
库 查 询 。Retrofit (参见 8.1.2 节 ) 是 一 个 由 异步 HTTP 调用 作为 支撑 的 Observable 源 。 在 
数据 库 访 问 方 面 ， 本 书 花费 了 很 多 的 时 间 讨 论 SQL 数据 库 (参见 5.3 节 )， 因 为 JDBC API 
的 设计 ， 它 们 一 直 以 来 都 是 阻塞 式 的 。 在 这 方面 ， NoSQL 数据 库 更 加 现代 化 ， 通 常会 提 
供 异 步 、 非 阻塞 的 客户 端 驱动 。 本 节 将 会 简要 介绍 Couchbase 和 MongoDB 驱动 ， 它 们 对 
RxJava 提供 了 原生 支持 ， 能 够 为 外 部 调用 返回 0bservable。 





































































































8.3.1 Couchbase 客 户 端 AP| 


Couchbase 服务 器 是 NoSQL 家 族 中 的 一 款 现代 文档 数据 库 。 有 意思 的 是 ， 在 客户 端 API 
中 ，Couchbase 支持 将 RxJava 作为 一 等 公民 。 在 与 数据 库 进 行 交 互 的 时 候 ，Reactive 
Extensions 不 仅仅 用 作 包 装 器 ， 还 得 到 了 Couchbase 的 官方 支持 和 常见 的 用 法 。 很 多 其 他 
的 存储 引擎 都 有 非 阻塞 、 异 步 的 API， 但 是 Couchbase 选择 将 RxJava 作为 客户 端 层 的 最 佳 
基础 。 


查询 名 为 travel-sample 的 示例 数据 集 作为 样 例 ， 它 有 一 个 ID 为 route_14197 的 文档 。 在 
示例 数据 集中 ， 路 由 文档 如 下 所 示 。 


£ 
"id": 14197, 
"type": "route", 
"airline": "B6", 
"airlineid": "airline 3029", 
"sourceairport": "PHX", 
"destinationairport": "BOS", 
"stops": 0， 
"equipment": "320", 
"schedule": [ 
{ 
"day": 0， 
"utc": "22:12:00", 

















"flight": "B6928" 


"day": 0, 
"utc": "06:40:00" 
"flight": "B6387" 


四 


"day": 1, 
"utc": "08:16:00" 
"flight": "B6922" 


- 


每 次 查询 都 会 返回 一 个 Observable， 此 时 ， 样 例 就 可 以 安全 地 按照 我 们 认为 合适 的 方式 转 
换 获取 的 记录 。 


CouchbaseCluster cluster = CouchbaseCLuster .create(); 
cluster 
.OpenBucket("travel-sample") 
.get("route 14197") 
.map(AbstractDocument: :content) 
.map(json -> json.getArray("schedule")) 
.concatMapIterable(JsonArray: :toList) 
.cast(Map.class) 
.filter(m -> ((Number)m.get("day")).intValue() == 0) 
.map(m -> m.get("flight").toString()) 
.Subscribe(flight -> System.out.printLn(fLight) ); 








AsyncBucket .get() 会 返回 一 个 0bservabLe<JsonDocument>。JSON 文档 本 质 上 是 松散 类 型 
的 ， 所 以 为 了 抽取 有 意义 的 信息 ， 样 例 必 须根 据 预 先 掌 担 的 结构 对 其 进行 遍历 。 

在 掌握 了 文档 的 格式 之 后 ， 理 解 对 JsonDocument 的 转换 就 非常 容易 了 。 转 换 过 程 首 先 会 抽 
取 schedule 元 素 ， 然 后 过 滤 所 有 day 为 6 的 节点 ， 并 最 终 得 到 fLight 节点 。0bserver 最 
后 得 到 的 是 86928、B6387 这 样 的 字符 串 。 令 人 惊讶 的 是 ，RxJava 同样 适用 于 如 下 场景 。 

。 数据 检索 ， 包 括 超时 、 缓 存 以 及 错误 处 理 。 

。 数据 转换 ， 如 提取 、 过 滤 、 数 据 钻 取 和 聚合 。 

这 个 样 例 展示 了 0bservable 抽象 的 强大 功能 ， 它 能 够 将 同样 简洁 的 API 用 到 各 种 不 同 的 场 


二 3 
是 o 


























8.3.2 MongoDB 客 户 端 API 

与 Couchbase 类 似 ，MongoDB 允许 存储 任意 的 类 JSON 的 文档 ， 而 无 须 预 先 定义 模式 。 客 
户 端 库 对 RxJava 提供 了 良好 的 支持 ， 人 允许 异步 存储 和 查询 数据 。 如 下 的 样 例 展示 了 这 两 
种 功能 。 它 首先 插入 12 条 文档 到 数据 库 ， 批 量 插入 完成 后 ， 就 会 将 数据 再 查询 出 来 。 


























注 3: 这 个 特性 类 似 于 .NET 平台 上 的 语言 集成 查询 (Language Integrated Query，LINQ ) 。 
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import com.mongodb.rx.client.*; 
import org.bson.Document; 
import java.time.Month; 


MongoCollection<Document> monthsColl = MongoClients 
.Create() 
.getDatabase("rx" 
.getCollection("months"); 


Observable 
.from(Month.values()) 
.map(month -> new Document() 
.append("name", month.name()) 
.append("days_not_Leap" ，month.Length(faLse)) 
.append("days_leap", month.length(true)) 


.toList() 

.flatMap(monthsColl: :insertMany) 

.flatMap(s -> monthsColl.find().toObservable()) 
.toBlocking() 

.Subscribe(System.out::println); 


Month 是 一 个 enum 类 ， 具 有 从 January 到 December 的 值 ， 我 们 还 可 以 获取 头 年 和 非 装 年 任 
意 月 份 的 长 度 。 首 先 ， 创 建 12 个 BSON (二 进 制 JSON) 文档 ， 每 个 代表 一 个 月 份 及 其 长 
度 。 然 后 ， 使 用 MongoCollection 的 insertMany() 方法 批量 插入 List<Document>。 这 个 操 
作 会 生成 Observable<Success> (这 个 值 本 身 并 不 包含 任何 有 意义 的 信息 ， 它 是 单 例 的 )。 
Success 事件 出 现 的 时 候 ， 通 过 调用 find().to0bservablte() 查询 数据 库 。 我 们 希望 刚刚 插 
入 的 12 条 文档 都 能 找到 。 为 了 简洁 起 见 ， 这 里 移 除 了 自动 分 配 的 _td 属性 ， 最 终 打 印 的 
结果 如 下 所 示 。 
Document{{name=JANUARY, days_not_leap=31, days_leap=31}} 


Document{{name=FEBRUARY, days_not_leap=28, days_leap=29}} 
Document{{name=MARCH, days_not_ leap=31, days_leap=31}} 
































再 次 强调 一 遍 ， 真 正 的 威力 源 于 组 合 。 借 助 MongoDB 的 RxJava 驱动 ， 我 们 可 以 很 容 
易 地 同时 查询 多 个 集合 ， 无 须 过 多 关注 细节 就 能 实现 并 发 。 如 下 的 代码 片段 发 起 了 两 
个 对 MongoDB 的 并 发 请 求 ， 另 外 还 发 起 了 一 个 对 定价 服务 的 请 求 。 注 意 ，first() 并 
不 是 Observable 的 操作 符 ， 而 是 MongoDB 的 操作 符 ， 它 会 在 构造 查询 之 后 返回 一 个 
Observable。find() 等 价 于 SQL 中 的 WHERE 子 句 ，projection() 代表 SELECT.first()， 这 
类 似 于 LIMIT 1。 


Observable<Integer> days = db.getCollection("months") 
.find(Filters.eq("name", APRIL.name())) 
.projection(Projections.include("days_not_leap")) 
.first() 

.map(doc -> doc.getInteger("days_not_ leap")); 

Observable<Instant> carManufactured = db.getCollection("cars" 
.find(Filters.eq("owner.name", "Smith")) 

.first() 











下 











大 
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.map(doc -> doc.getDate("manufactured")) 
.map(Date: :toInstant); 


Observable<BigDecimal> priceperDay = dailyPrice(LocalDateTime.now()); 
Observable<Insurance> insurance = Observable 

.Zip(days, carManufactured, priceperDay, 

(d, man, price) -> { 
// 创 建 保险 数据 

]); 
从 技术 上 讲 ， 我 们 可 以 混合 任意 的 Observable， 而 不 用 关心 其 特点 和 来 源 。 上 述 样 例 发 
起 了 针对 不 同 集合 的 两 个 MongoDB 查询 ， 还 有 另外 一 个 dailyPrice() 查询 ， 它 可 能 是 
Retrofit 发 起 的 HTTP 调用 ， 该 查询 返回 的 是 一 个 0Observable。 底 线 是 : 0bservable 的 来 源 
无 关 紧 要 ， 我 们 可 以 任意 地 组 合 异 步 计算 和 请 求 。 你 是 否 计划 将 多 个 数据 库 查 询 与 网 络 服 
务 、 本 地 文件 系统 操作 结合 在 一 起 呢 ? 所 有 这 些 操作 都 可 以 并 发 运行 ， 并 且 可 以 同样 容易 
地 组 合 在 一 起 。 和 掌握 了 RxJava 整体 是 如 何 运 行 的 之 后 ， 就 会 发 现 每 个 0bservablte 源 在 表 
面 上 都 是 相同 的 。 


8.4 Camel 集 成 


8.1.2 节 介 绍 了 如 何 借助 RxJava 的 支持 发 起 HITP 请 求 。 但 是 ， 还 有 很 多 其 他 的 方式 进 
行 系统 集成 ， 其 中 很 大 一 部 分 都 内 置 到 了 Apache Camel 框架 中 。Camel 有 一 组 令 人 赞叹 
的 集成 组 件 ， 借 助 它们 ， 我 们 可 以 与 200 多 个 平台 连接 和 交换 抽象 消息 。 这 些 平台 包括 
AMQP、Amazon Web Services、Cassandra、ElasticSearch、 文 件 系 统 、FTP、Google API、 
JDBC、Kafka、MongoDB、SMTP、XMP 等 。 大 多 数组 件 都 能 推送 抽象 消息 到 客户 端 ， 举 
例 来 说 ， 这 样 的 消息 包括 收 到 新 的 Email 或 者 文件 系统 中 的 新 文件 。 


Camel 还 提供 了 RxJava 适配器 ， 从 而 以 声明 式 、 反 应 式 的 方式 使 用 传 入 的 消息 。 


8.4.1 通过 Camel 来 消费 文件 

借助 RxJava 的 0bservabte 和 操作 符 ， 我 们 可 以 按照 统一 的 方式 集成 数 百 种 平台 。 例 如 ， 

假设 我 们 想 要 监控 文件 系统 的 新 文件 (与 4.8 节 进 行 对 比 ) 。 由 于 Camel 对 RxJava 的 支持 ， 

以 下 任务 会 非常 简单 。 
CamelContext camel = new DefaultCamelContext(); 
ReactiveCamel reactiveCamel = new ReactiveCamel(camel); 









































reactiveCamel 
.toObservable("file:/home/user/tmp") 
.Subscribe(e -> 
log.info("New file: {}", e)); 


这 样 就 可 以 了 ! 在 创建 完 DefaultCamelContext 和 ReactiveCamel 之 后 ， 就 可 以 开始 消费 消息 
了 。Camel 支持 的 每 个 集成 平台 都 会 通过 URI 的 方式 进行 编码 ， 在 这 个 场景 中 就 是 file:/ 
home/user。 使 用 这 个 URI 来 调用 toObservable() 就 能 得 到 一 个 通用 的 Observable<Message>， 
每 次 在 指定 的 目录 中 有 新 文件 出 现 ， 它 就 会 发 布 一 个 事件 。 对 于 每 种 集成 平台 ，URI 本 身 会 
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有 数 十 个 配置 项 。 比 如 ， 通 过 为 fileURI 添 加 ?recursive=true&noop=true 配置 ， 我 们 要 求 
Camel 递归 查找 文件 ， 并 且 在 发 现 文件 后 不 删除 它们 。 


8.4.2 ”接收 来 自 Kafka 的 消息 
消费 轮 询 文件 系统 变化 来 得 到 数据 是 一 种 很 流行 的 集成 技术 。 但 是 ， 如 果 需 要 更 健壮 、 更 
快速 、 更 可 靠 的 通信 协议 ， 那 么 应 该 选择 基于 JMS 规范 的 消息 代理 (broker) 或 者 Kafka。 
Kafka 是 一 个 开源 的 发 布 一 订阅 消息 代理 。 按 照 设计 ， 它 默认 支持 容错 ， 每 秒 能 够 处 理 数 
十 万 条 消息 。Kafka 有 一 个 原生 的 Java API， 但 是 从 0bservable 的 角度 使 用 它 是 很 有 诱惑 
力 的 。 除 了 一 个 不 同 的 URI 之 外 ，Camel 集成 基本 相同 。 
reactiveCamel 
.toObservable("kafka:localhost:9092?topic=demo&groupId=rx") 
.map(Message: :getBody) 


.Subscribe(e -> 
log.info("Message: {}", e)); 


我 们 可 以 消费 来 自 几乎 所 有 平台 的 抽象 消息 ， 它 们 使 用 相同 的 0bservabLeAPI， 这 一 点 是 
非常 强大 的 。Camel 在 一 致 的 接口 背后 提供 了 必要 的 物理 连接 ， 而 RxJava 通过 大 量 的 操 
作 符 进一步 增强 了 该 API。 在 应 用 程序 中 ，Camel 和 Retrofit (参见 8.1.2 节 ) 是 开始 使 用 
Reactive Extensions 的 良好 起 点 。 在 拥有 了 稳定 的 Observables 源 之 后 ， 将 反应 式 行为 进 一 
步 扩 展 至 技术 栈 就 会 容易 得 多 。 


















































8.5 Java 8 的 Stream 和 CompLetabLeFuture 


有 了 时候 ， 人 们 对 于 该 选择 哪 种 抽象 进行 并 发 编程 可 能 会 觉得 困惑 ， 在 Java 8 之 后 更 是 如 

此 。 多 种 互相 竞争 的 API 都 能 以 非常 整洁 的 方式 表述 异步 计算 。 本 市 会 对 比 这 些 API， 帮 

助 你 选择 适合 工作 的 恰当 工具 。 可 用 的 抽象 包括 以 下 部 分 。 

口 CompletableFuture 
CompletableFuture 由 Java 8 引入 ， 这 是 对 java.util.concurrent 包 中 大 家 熟知 的 Future 
的 强大 扩展 。CompletableFuture 允许 Future 完成 或 失败 时 注册 异步 回调 ， 而 不 必 阻 
塞 等 竺 结果。 但 是 ， 它 真正 的 强大 之 处 在 于 组 合 和 转换 的 能 力 ， 这 类 似 于 0bservable. 
map() 和 flatMap() 提供 的 功能 。 尽 管 CompletableFuture 是 在 标准 JDK 中 引入 的 ,但 
是 在 Java 标准 库 中 并 没有 单个 类 依赖 或 使 用 它 。 虽 然 它 十 分 好 用 ， 但 是 还 没有 很 好 地 
集成 到 Java 生态 系统 中 。 要 了 解 它 与 RxJava 的 可 移植 性 问题 ， 请 参见 5.4.1 节 。 

口 并 行 (parallel ) 流 
与 CompletableFuture 类 似 ，java.util.strean 中 的 流 也 是 JDK 8 引入 的 。 流 是 一 种 能 
够 在 真正 执行 之 前 声明 操作 序列 的 方式 ， 比 如 映射 、 过 滤 等 。 流 上 所 有 的 操作 都 是 延 
述 执行 的 ， 直 到 使 用 了 像 collect() 或 reduce() 这 样 的 终端 操作 才 会 真正 执行 。 同 时 ， 
JDK 能 够 自动 在 可 用 的 核心 上 并 行 执行 某 些 操作 ， 这 听 起 来 非常 有 吸引 力 。 并 行 流 承 
诺 能 够 在 多 个 核心 上 透明 地 对 较 大 的 数据 集 进行 映射 、 过 滤 ， 其 至 排序 。 流 通常 由 集合 
生成 ,但 也 可 以 在 运行 时 动态 创建 元 素数 量 无 限 的 流 。 















































口 rx.Observable 
0bservablte 代表 了 一 个 事件 流 ， 而 事件 的 出 现时 间 是 无 法 预测 的 。 它 可 以 代表 零 个 、 一 
个 、 固 定数 量 或 无 限 数量 的 事件 ， 这 些 事件 可 以 立即 可 用 ， 也 可 以 随时 间 推 移 而 出 现 。 
完成 事件 或 错误 事件 都 可 以 终止 Observable。 现 在 ， 你 应 该 非常 熟悉 0bservable 了 。 


口 rx.Single 
RxJava 库 成 熟 之 后 ， 如 果 有 一 个 特殊 的 类 型 能 够 代表 有 和 且 仅 有 一 个 结果 ， 那 会 有 很 大 
的 助 益 。Single 类 型 的 流 要 么 有 且 仅 有 一 个 值 并 正常 完成 ， 要 么 出 现 错误 。 在 某 种 程 
度 上 ，Single 与 CompletableFuture 非常 类 似 ， 但 Single 是 延迟 执行 的 ， 这 意味 着 在 订 
阅 之 前 ， 它 不 会 开始 计算 。5.5 节 对 single 进行 了 描述 。 

口 rx.Completable 
有 时 候 调 用 特定 的 计算 纯粹 是 为 了 它 的 副作用 ， 而 不 期 望 得 到 任何 的 结果 。 这 样 的 例子 
包括 发 送 Email 或 者 保存 数据 库 记 录 ， 这 种 操作 涉及 IO (这 可 以 从 异步 处 理 中 收益 )， 
但 是 并 不 会 返回 有 意义 的 结果 。 传 统 上 ， 这 种 场景 会 使 用 CompletableFuture<Void> 或 
observable<Void>。 但 是 ， 具 体 的 Comptetabte 类 型 能 够 更 清晰 地 表明 执行 异步 计算 却 
没有 结果 返回 的 意图 。 在 并 发 执行 中 ，Completable 会 得 到 完成 或 错误 通知 ， 与 其 他 的 
Rx 类 型 相似 ， 它 也 是 延迟 执行 的 。 

显然 ， 还 有 其 他 表述 异步 计算 的 方式 ， 如 下 所 示 。 


。 Reactor 项 目 提供 的 FLux 和 Mono。 这 两 个 类 型 分 别 类 似 于 0bservabLe 和 Single。 
。 Guava 中 的 ListenableFuture。 


但 是 ， 为 了 使 可 选 方案 列表 保持 简短 ， 我 们 可 以 将 其 限定 在 JDK 和 RxJava 中 。 在 开始 
之 前 ， 需 要 说 明 ， 如 果 应 用 程序 已 经 非常 一 致 地 使 用 了 CompletableFuture， 那 么 我 们 
应 该 坚持 使 用 它 。CompletableFuture 提供 的 API， 有 一 些 比 较 策 重 ,但 是 整体 而 言 ， 这 
个 类 提供 了 对 反应 式 编 程 的 良好 支持 。 另 外 ， 我 们 期 望 越 来 越 多 的 框架 能 够 利用 这 一 点 
并 提供 惯用 支持 。 在 第 三 方 库 中 支持 RxJava 会 更 加 困难 ， 因 为 这 需要 额外 的 依赖 ， 而 
CompletableFuture 是 JDK 的 一 部 分 。 


8.5.1 并 行 流 的 用 途 


暂时 转移 一 下 话题 ， 讨 论 一 下 来 自 标准 JDK 的 并 行 流 。 在 Java 8 中 ， 如 果 你 需要 转换 一 个 
较 大 的 对 象 集合 ， 可 以 声明 以 并 行 的 方式 进行 转换 。 


List<Person> people = //... 
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List<String> sorted = people 
.parallelStream() 
.filter(p -> p.getAge() >= 18) 
.map(Person: :getFirstName) 
.Sorted(Comparator .comparing(String::toLowerCase)) 
.Collect(toList()); 


注意 ， 上 面 的 代码 片段 使 用 了 parallelsStream()， 而 不 是 传统 的 stream()。 通 过 使 用 
paraLLeLStrean()， 我 们 能 够 要 求 像 collect() 这 样 的 终端 操作 以 并 行 的 方式 执行 ， 而 不 
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是 以 序列 化 的 方式 。 当 然 ， 这 对 结果 不 会 有 任何 影响 ， 但 是 速度 会 更 快 一 些 。 在 底层 ， 
parallelstream() 会 将 输入 集合 切 分 为 多 个 块 ， 并 行 处 理 每 个 块 ， 然 后 按照 分 而 治之 的 原 
则 将 结果 组 合 在 一 起 。 


有 些 操作 符 很 容易 并 行 化 (比如 map() 和 fitter())， 其 他 操作 符 可 能 会 更 困难 一 些 ( 比 
如 sorted())。 因 为 在 对 每 个 块 分 别 排序 之 后 ， 必 须 再 将 它们 组 合 在 一 起 ， 在 排序 的 场景 
下 ， 这 就 意味 着 需要 对 两 个 有 序 的 序列 进行 合并 。 如 果 没 有 进一步 的 假设 条 件 ， 有 些 操作 
符 很 难 或 者 无 法 并 行 化。 例如 ，reduce() 只 有 在 累加 函数 是 可 结合 的 时 候 ， 才 能 进行 并 
行 化 。 

















相同 的 结果 ? 
有 些 操作 符 在 分 别 使 用 顺序 化 stream() 和 parallelstream() 时 可 能 产生 
不 同 的 结果 。 例 如 ，findFirst() 操作 符 会 返回 流 中 遇 到 的 第 一 个 元 素 。 而 
findAny() 操作 符 似 乎 完成 的 是 相同 的 事情 。 但 是 ，findFirst() 始终 都 会 返回 
流 中 第 一 个 元 素 ，findAny() 则 可 以 在 并 行 流 执行 的 时 候 返 回流 中 任意 一 个 值 。 

有 可 能 发 生 这 样 的 情况 ， 在 findFirst() 或 findAny() 之 前 使 用 了 filter() 
操作 符 。parallelstream() 的 执行 可 以 任意 切 分 输入 流 ， 假 设 将 其 切 分 成 了 
两 部 分 ， 然 后 分 别 对 这 两 部 分 执行 过 滤 。 如 果 对 后 半 部 分 的 过 滤 首 先 产生 了 
匹配 的 值 ，findAny() 就 会 返回 这 个 值 ， 即 使 前 半 部 分 有 匹配 的 值 也 会 如 此 。 
findFirst() 能 够 保证 返回 全 局 第 一 个 匹配 的 值 ， 所 以 它 必 须 等 待 这 两 部 分 
的 过 滤 结 果 。 两 个 方法 各 有 其 优点 ， 应 该 慎重 使 用 。 









































在 一 台 具 备 4 个 CPU 的 机 器 上 应 用 Amdahl 定律 ， 理 想 情 况 下 ， 执 行 的 速度 要 快 4 倍 。 但 
是 ， 并 行 流 有 自己 的 缺点 。 首 先 ， 如 果 流 的 规模 比较 小 而 且 转 换 管 道 比 较 短 ， 那 么 上 下 文 
切换 的 成 本 就 会 非常 高 ， 甚 至 可 能 出 现 并 行 流 比 顺序 流 更 慢 的 情况 。 这 种 过 于 细 粒 度 的 并 
发 问题 在 RxJava 中 也 有 可 能 出 现 ， 因 此 它 支 持 通 过 scheduler (参见 4.9.1 节 ) 进行 声明 
式 的 并 发 。 这 种 并 行 流 的 情况 则 有 所 不 同 。 

有 没有 想 过 为 什么 这 个 框架 叫 作 并 行 流 而 不 是 并 发 (concurrent) 流 ? 按照 设计 ， 并 行 流 仅 
适用 于 CPU 密集 型 的 任务 ， 它 有 一 个 硬 编码 的 线程 地 (确切 地 说 ， 是 ForkJoinPool)， 根 
据 我 们 拥有 的 CPU 数量 进行 分 配 。 这 个 池 可 以 通过 ForkJoinpPool.commonPool() 全 局 静态 
访问 。JVM 中 的 每 个 并 行 流 以 及 一 些 CompletableFuture 回调 会 共享 该 ForkJoinPool。 整 
个 JVM (所 以 ， 如 果 在 应 用 程序 服务 器 中 部 署 多 个 WAR 文件 ， 这 意味 着 会 有 多 个 应 用 程 
序 ) 中 的 所 有 并 行 流 共享 同一 个 较 小 的 池 。 这 样 是 没有 问题 的 ， 因 为 按照 设计 并 行 流 用 于 
并 行 的 任务 ， 它 确实 需要 在 这 段 时 间 内 CPU 达到 100%。 因 此 ， 如 果 多 个 并 行 流 并 发 执 
行 ， 无 论 怎样 它们 肯定 都 会 争 用 CPU 。 

但 是 ,假设 有 一 个 自私 的 应 用 程序 ， 它 在 并 行 流 中 执行 了 1O 操作 。 


// 不 要 这 样 做 

people 
.paraLLeLStream() 
.forEach(this: :publishOverJms); 
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publishOverJms() 会 为 流 中 的 每 个 人 发 送 一 条 JMS 消息 。 我 们 故意 选择 使 用 JMS 进行 发 
送 。 它 看 上 去 很 快 ， 但 是 为 了 保证 投递 成 功 ， 发 送 JMS 很 可 能 会 涉及 网 络 (通知 消息 代 
理 ) 或 磁盘 (在 本 地 持久 化 消息 )。 这 个 微小 的 1O 延迟 足以 占用 宝贵 的 ForkJoinPool. 
commonPool() 线程 很 长 时 间 。 即 便 这 个 程序 没有 使 用 CPU，JVM 中 的 其 他 代码 也 无 法 执行 
并 行 流 了 。 现 在 ， 设 想 一 下 ， 如 果 这 个 程序 不 是 通过 JMS 发 送 消 息 ， 而 是 通过 网 络 服务 检 
索 数 据 ， 或 者 运行 代价 高 郧 的 数据 库 查询 。parallelstream() 只 能 用 于 完全 CPU 密集 的 任 
务 ， 否则，JVM 的 性 能 会 受到 严重 的 影响 。 


这 并 不 是 说 并 行 流 不 好 。 但 是 ， 线 程 池 的 数量 是 固定 的 ， 所 以 它们 的 应 用 场景 较为 有 限 。 
当然 ， 来 自 JDK 的 并 行 流 并 不 是 0bservable.flatMap() 或 其 他 并 发 机 制 的 替代 方案 。 并 行 
流 在 并 行 执行 的 时 候 效 果 最 好 。 但 是 ， 对 于 不 要 求 CPU 100% 占用 的 并 发 任务 (比如 会 有 
网 络 或 磁盘 阻塞 的 场景 )， 最 好 使 用 其 他 机 制 。 


了 解 了 流 的 局 限 性 ， 接 下 来 对 比 一 下 future 和 RxJava， 看 看 它们 最 适合 什么 样 的 场景。 


8.5.2 选择 恰当 的 并 发 抽象 


在 RxJava 中 ， 与 CompletableFuture 最 接近 的 就 是 Single 了。 我 们 也 可 以 使 用 
Observable， 不 过 需要 注意 它 会 发 布 任意 数量 的 值 。future 和 RxJava 类 型 有 一 个 很 大 的 区 
别 ， 即 后 者 是 延迟 执行 的 。 得 到 一 个 CompletableFuture 引用 时 ， 我 们 就 可 以 确定 后 台 计 
算 已 经 开始 了 ， 而 Single 和 0bservable 很 可 能 在 订阅 之 后 才 会 开始 工作 。 了 解 了 这 种 语 
义 上 的 差异 ， 我 们 就 可 以 很 容易 地 交替 使 用 CompletableFuture、Observable (参见 5.4 节 ) 
和 Single (参见 5.5.3 节 ) 了 。 


在 某 些 罕见 情况 下 ， 无 法 获取 异步 计算 的 结果 ， 或 者 结果 本 身 无 关 紧 要 ， 那 么 可 以 使 用 
CompletableFuture<Void> 或 Observable<Void>。 前 者 比较 简单 ， 而 后 者 可 能 上 暗示 着 一 个 空 
事件 形成 的 潜在 无 穷 流 。rx.Single<Void> 是 一 种 糟糕 的 用 法 ， 与 Future 中 返回 的 void 类 
似 。 因 此 ，RxJava 引入 了 rx.Completable。 如 果 我 们 的 架构 有 很 多 操作 ， 却 不 会 形成 有 意 
义 的 结果 (不 过 可 能 会 有 异常 )， 那 么 可 以 考虑 使 用 Completable。 举 例 来 说 ， 在 命令 查询 
分 离 模式 架构 (Command-Query Separation，CQS) 中 ， 命 令 是 异步 的 ， 而 且 按 照 定 义 它 
们 不 会 返回 任何 结果 。 


8.5.3” 何 时 使 用 0bservable 


如 果 我 们 的 应 用 程序 要 处 理 随 时 间 而 出 现 的 事件 流 ( 比 如 用 户 登 录 、GUI 事件 以 及 推送 
通知 )， 那 么 Observable 是 不 二 之 选 。 本 书 虽然 没有 提 及 ， 但 是 Java 从 1.0 版 本 就 开始 
提供 java.util.0bservable 了 ， 它 允许 注册 0bserver 和 获取 通知 。 不 过 ， 它 在 如 下 方 再 
有 所 欠缺 。 


。 组 合 的 能 力 (没有 操作 符 )。 

。 泛 型 (0bserver 有 一 个 update() 方法 ， 该 方法 接收 0bject， 代 表 任意 的 通知 载荷 ) 。 
。 性 能 (到 处 使 用 synchronized 关键 字 ， 内 部 使 用 java.util.vVector ) 。 

。 关注 点 分 离 (在 某 种 意义 上 讲 ， 它 把 0bservable 和 Publishsubject 组 合 在 了 一 起 )。 
。 对 并 发 的 支持 (所 有 的 Observer 都 是 顺序 通知 的 )。 
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不 可 变性 。 


在 标准 Java 中 ，JDK 中 的 0bservable 是 声明 式 建 模 的 事件 的 最 好 方案 ， 其 次 是 GUI 包 
中 的 addListener() 方 法。 如 果 领 域 明确 涉及 事件 或 数据 流 ， 那 么 很 少 有 方案 能 够 打败 
rx.0bservable<T>。 声 明 式 的 表述 方式 再 加 上 大 量 的 操作 符 ， 能 够 解决 大 部 分 的 问题 。 对 
于 cold 类 型 的 observabte， 我 们 可 以 通过 回 压 控 制 吞 吐 量 ， 对 于 hot 类 型 的 Observable， 
可 以 使 用 很 多 流 控制 操作 符 ， 比 如 buffer()。 


8.6 ”内存 耗 费 和 泄漏 


RxJava 是 关于 事件 流 的， 这 些 事件 在 运行 时 的 内 存 中 处 理 。 它 提供 了 一 致 且 丰 富 的 API， 
将 事件 源 的 细节 进行 了 抽象 。 理 想 情 况 下 ， 在 内 存 中 应 该 只 保留 数量 有 限 的 一 组 固定 事 
件 ， 即 从 发 布 事件 的 生产 者 到 存储 或 转发 事件 的 消费 者 之 间 的 事件 。 在 现实 中 ， 有 些 组 
件 ， 尤 其 是 被 误 用 的 时 候 ， 消 耗 的 内 存 可 能 不 受 任 何 限制 。 显 然 ， 内 存 是 有 限 的 ， 我 们 最 
终 可 能 会 遇 到 OutofMemoryError 或 无 休止 的 垃圾 收集 周期 。 本 节 将 会 介绍 几 个 在 RxJava 
中 内 存 消耗 不 受 控制 和 内 存 泄漏 的 样 例 ， 以 及 如 何 避 免 这 种 情况 。Android 的 相关 章节 介 
绍 了 一 种 特殊 类 型 的 内 存 泄漏 ， 与 忘记 取消 订阅 相关 ， 参 见 8.1.1 节 。 


没有 内 存 资源 消耗 限制 的 操作 符 

有 些 操 作 符 可 能 会 消耗 任意 数量 的 内 存 ， 消 耗 量 完全 取决 于 流 的 特性 。 接 下 来 介绍 几 个 这 
样 的 操作 符 ， 并 尝试 采取 一 些 措 施 以 避免 内 存 泄 漏 。 

1. distinct() 缓 存 见 过 的 所 有 事件 

例如 ， 按 照 定 义 ，distinct() 必须 存储 自 订 阅 以 来 见 过 的 所 有 key。distinct() 默认 的 
重 载 版 本 会 借助 一 个 内 部 的 缓存 集 ， 对 比 目 前 为 止 见 过 的 所 有 事件 。 如 果 相 同 的 事件 
(根据 equals() 方法 进行 判断 ) 没有 出 现 ， 这 个 事件 会 被 发 布 ， 并 且 添 加 到 缓存 中 以 备 
未 来 使 用 。 这 个 缓存 永远 不 会 被 驱逐 ,“ 以 保证 相同 的 事件 不 会 再 次 出 现 。 很 容易 想到 ， 
如 果 事 件 非常 大 或 者 事件 出 现 得 非常 频繁 ， 那 么 这 个 内 部 缓存 会 持续 增长 ， 从 而 导致 内 
存 泄漏 。 


为 了 方便 益 述 ， 使 用 如 下 事件 模拟 大 块 数据 。 


class Picture { 
private final byte[] blob = new byte[128 * 1024]; 
private final long tag; 





































































































picture(long tag) { this.tag = tag; } 


@Override 
public boolean equaLs(Object o) { 
if (this == 0) return true; 


if (!(o instanceof Picture)) return false; 
Picture picture = (Picture) o; 





注 4: 它 实 际 上 是 RxJaval.1.6 中 的 HashSet。 
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return tag == picture.tag; 


} 


@Override 
public int hashCode() { 

return (int) (tag ^ (tag >>> 32)); 
} 


@Override 
public String toString() { 
return Long.toString(tag); 
} 
} 


下 面 的 程序 会 在 一 个 内 存 很 有 限 的 环境 中 运行 〈-mx32M: 32 MB 的 堆 )， 并 且 尽 可 能 快 地 发 
布 非常 大 的 事件 。 
Observable 
.range(0, Integer .MAX_VALUE) 
.map(Picture: :new) 
.distinct() 
.Sample(1, TimeUnit.SECONDS) 
.Subscribe(System.out: :println); 


运行 之 后 ， 很 快 就 会 出 现 0utofMemoryError， 因 为 distinct() 内 部 的 缓存 无 法 盛 放 更 多 
Picture 实例 。 在 崩 泪 之前， 因为 垃圾 收集 器 努力 释放 空间 ，CPU 的 使 用 率 也 非常 高 。 但 
是 ， 即 便 不 使 用 整个 Picture 作为 区 分 事件 的 key， 只 使 用 Picture.tag 进行 区 分 ， 程 序 依 
然 会 崩溃 ， 只 不 过 出 现 的 时 间 会 晚 很 多 。 


distinct(Picture::getTag) 


这 种 类 型 的 泄漏 甚至 更 危险 。 在 我 们 没有 注意 到 的 时 候 ， 这 种 问题 变 得 越 来 越 严 重 ， 直 到 
在 意料 之 外 的 时 刻 爆发 ， 通 常 是 在 高 负载 的 情况 下 。 为 了 证 明 distinct() 是 内 存 泄 漏 的 根 
源 ， 可 以 运行 一 个 类 似 的 程序 。 该 程序 不 使 用 distinct()， 而 是 统计 在 没有 任何 的 缓冲 的 
情况 下 每 秒 发 布 事 件 的 数量 。 你 的 数量 级 可 能 会 有 所 差异 ， 但 是 下 面 的 程序 每 秒 能 处 理 成 
千 上 万 条 大 型 消息 ， 并 不 会 对 垃圾 收集 和 内 存 带 来 太 大 压力 。 
Observable 

.range(0, Integer .MAX_VALUE) 

.map(Picture: :new) 

.window(1, TimeUnit.SECONDS) 


.flatMap(Observable: :count) 
.subscribe(System.out::println); 


那么 ， 该 如 何 避 免 distinct() 相关 的 内 存 汇 漏 呢 ? 

。 完全 避免 使 用 distinct()。 这 种 方法 最 简单 ,如 果 使 用 不 当 , 这 个 操作 符 本 身 是 很 危险 的 。 

。 明智 地 选择 key。 理想 情况 下 ,key 应 该 占据 有 限 且 很 小 的 空间 。enum 和 byte 都 是 可 以 的 ， 
但 是 Long 或 String 可 能 不 行 。 如 果 无 法 确定 给 定 的 类 型 是 否 只 具有 有 限 的 值 ( 像 enum 
这 样 )， 那 么 可 能 会 有 内 存 泄漏 的 风险 。 
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。 考虑 使 用 distinctuntilchanged() 作为 替代 方案 ， 它 只 会 跟踪 最 后 一 个 见 到 的 事件 ， 而 
不 是 所 有 事件 。 

。 从 一 开始 ， 我 们 真 的 需要 唯一 性 吗 ， 这 个 需求 能 否 放 松 ? 或 者 能 否 以 某 种 方式 断定 ， 
重复 的 值 只 会 在 10 秒 之 内 出 现 ? 如 果 是 这 样 ， 可 以 考虑 在 一 个 很 小 的 窗口 中 运行 
distinct() 。 









































Observable 
.range(0, Integer .MAX_VALUE) 
.map(Picture: :new) 
.Window(10, TimeUnit.SECONDS) 
.flatMap(Observable: :distinct) 


样 例 每 10 秒 会 开启 一 个 新 的 窗口 (参见 6.1.2 节 ) 并 确保 在 这 个 窗口 中 没有 重复 的 值 。 
window() 会 发 布 一 个 0bservable， 这 个 Observable 包含 了 每 个 时 间 窗 口内 的 所 有 事件 。 在 
这 个 窗口 中 ,唯一 的 值 (通过 distinct() 判断 ) 会 立即 发 布 。10 秒 的 窗口 结束 时 ， 将 开 
启 一 个 新 的 窗口 ， 但 更 重要 的 是 ， 旧 窗口 关联 的 缓存 会 被 垃圾 收集 。 当 然 ， 在 这 10 秒 之 
内 ， 依 然 有 可 能 遇 到 数量 较 多 的 事件 ， 从 而 导致 0utofMemoryError。 所 以 ， 我 们 最 好 采用 
固定 长 度 的 窗口 〈 比 如 window(1060) ) ， 而 不 是 固定 时 间 的 窗口 。 另 外 ， 如 果 在 一 个 窗口 
的 结尾 和 另 一 个 窗口 的 开端 出 现 了 相同 的 事件 ， 那 么 样 例 将 无 法 辨别 重复 的 事件 。 这 是 我 
们 必须 要 注意 的 权衡 。 

2. 通过 toList() 和 buffer() 缓 冲 事件 

显然 ，toList() 会 耗费 无 限 的 内 存 。 另 外 ， 对 无 穷 流 使 用 toList() 没有 任何 意义 。toList() 
只 会 在 上 游 源 完成 的 时 候 发 布 一 个 事件 ， 如 果 上 游 不 完成 ，toList() 不 会 发 布 任何 内 容 。 但 
是 它 会 在 内 存 中 聚合 所 有 事件 。 对 很 长 的 流 使 用 toList() 也 是 有 问题 的 。 我 们 应 该 以 某 种 
方式 在 运行 时 消费 事件 ， 或 者 使 用 像 take() 这 样 的 操作 符 限 制 上 游 事件 的 数量 。 

如 果 你 想 要 同时 查看 有 限 0bservable 中 的 所 有 事件 ， 那 么 toList() 是 很 有 用 的 。 这 种 情 
况 很 少见 ， 我 们 可 以 使 用 谓词 (如 altMatch() 和 anyMatch())、 计 数 (count()) 或 者 将 它 
们 约 减 到 一 个 聚合 值 (reduce()) 中 ， 这 样 能 够 避免 同时 在 内 存 中 保留 所 有 的 事件 。 如 下 
的 用 例 将 0bservable<0bservable<T>> 转换 成 0bservabLe<List<T>>， 内 部 Observable 的 长 
度 是 固定 的 。 


.window(100) 
.flatMap(Observable: :toList) 


这 等 价 于 以 下 代码 。 
.buffer(100) 


在 使 用 buffer() 之 前 ， 仔 细 思 考 一 下 ， 我 们 是 否 真 的 需要 用 某 个 时 间 段 内 所 有 事件 组 成 
的 List<T >。 也 许 ， 使 用 一 个 0Observable<T> 就 足够 了 。 举 例 来 说 ， 如 果 我 们 想 要 知道 每 秒 
形成 的 Observable<Incident> 中 ， 高 优先 级 的 事件 数量 是 否 超过 5 件 ， 那 么 需要 生成 一 个 
Observable<Boolean>， 每 秒 都 发 布 true 或 false。 如 果 给 定 的 1 秒 内 ， 发 生 了 大 量 的 高 优 
先 级 的 事件 ， 那 么 会 发 布 true; 否则 ， 发 布 false。 借 助 buffer()， 这 个 功能 实现 起 来 非 
常 简单 。 











































































































Observable<Incident> incidents = //... 


Observable<Boolean> danger = incidents 
.buffer(1, TimeUnit.SECONDS) 
.map((List<Incident> oneSecond) -> oneSecond 
.Stream() 
.filter(Incident::isHIghpriority) 
.count() > 5); 


但 是 ，window() 并 不 需要 将 事件 缓冲 到 一 个 中 间 List 中 ， 而 是 直接 在 运行 时 向 下 转发 。 
window() 也 能 非常 便利 地 完成 相同 的 任务 ， 而 且 保证 了 固定 的 内 存 消耗 。 


Observable<Boolean> danger = incidents 
.window(1, TimeUnit.SECONDS) 
.flatMap( (Observable<Incident> oneSecond) -> 
oneSecond 
.filter(Incident::isHIghpriority) 
.Count() 
.map(c -> (C > 5)) 











) ; 


相对 于 JD 玉 中 的 Stream，0bservabLe 有 更 加 丰富 的 API， 所 以 你 可 能 会 发 现 ， 将 Java 的 
Collection 转换 成 0bservablte 只 是 为 了 能 够 使 用 更 好 的 操作 符 。 例 如 ，Stream 并 不 支持 请 
动 窗口 和 压缩 。 


所 以 ， 如 果 条 件 允 许 ， 我 们 应 该 优先 使 用 window()， 而 不 是 buffer()， 尤 其 是 buffer() 内 
部 累积 的 List 的 长 度 无 法 预测 和 管理 的 时 候 。 


3. 通过 cache() 和 RepLaySubject 进 行 缓存 

cache() 是 另外 一 个 明显 会 消耗 内 存 的 操作 符 。 比 distinct() 更 糟糕 的 是 ，cache() 会 保留 
从 上 游 接 收 到 的 每 个 事件 的 引用 。 只 有 0bservable 的 长 度 固定 且 元 素数 量 较 少 的 时 候 ， 使 
用 cache() 才 有 意义 。 例 如 ， 如 果 使 用 0bservable 来 建 模 某 个 组 件 的 异步 响应 ， 那 么 使 用 
cache() 是 安全 可 行 的 ， 否 则 ，observer 会 再 次 触发 请 求 ， 可 能 会 造成 难以 预料 的 副作用 。 
相反 ， 如 果 缓 冲 很 长 或 无 穷 Observable， 尤 其 是 hot 类 型 的 0bservabte， 使 用 cache() 其 实 
没有 太 大 的 意义 。 如 果 是 hot 类 型 的 Observable， 我 们 其 实 很 可 能 根本 就 不 关心 历史 事件 。 


相同 的 情况 适用 于 Replaysubject (参见 2.6 节 )。 这 类 subject 中 的 任何 内 容 都 必须 进行 
存储 ， 这 样 ， 后 续 的 Observer 能 够 看 到 所 有 的 通知 ， 而 不 仅仅 是 未 来 的 通知 。 对 cache() 
和 RepLaySubject 的 建议 几乎 是 相同 的 。 如 果 你 在 使 用 它们 ， 那 么 就 要 确保 缓存 产 是 有 限 
的 ， 并 且 元 素 的 长 度 要 相对 较 短 。 另 外 ， 不 要 长 期 保持 对 缓存 0bservabte 的 引用 ， 否 则 ， 
一 段 时 间 之 后 可 能 会 触发 垃圾 收集 。 
4. 回 压 能 够 保持 内 存 使 用 处 于 较 低 的 水 平 
3.2.3 市 介绍 了 如 何 将 两 个 事件 生成 节奏 不 同 的 源 压缩 在 一 起 。 如 果 想 要 压缩 两 个 产 ， 这 两 
个 源 中 有 一 个 要 比 另 一 个 稍 慢 一 些 ， 那 么 zip()/ztpWith() 操作 符 必须 要 临时 缓冲 较 快 的 
流 ， 同 时 等 待 较 慢 的 流 所 对 应 的 事件 。 

Observable<Picture> fast = Observable 


.interval(10, MICROSECONDS) 
.map(Picture: :new); 
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Observable<Picture> slow = Observable 
.interval(11, MICROSECONDS) 
.map(Picture: :new); 


Observable 
.Zip(fast, slow, (f, s) ->f+":"+ Ss) 


你 可 能 认为 上 述 代码 会 因为 0utofMemoryError 而 崩溃， 认为 zip() 要 不 断 增加 来 自 fast 
的 事件 的 缓冲 并 等 待 sLow 流 。 但 事实 并 非 如 此 。 实 际 上 ， 样 例 几 乎 立即 就 会 遇 到 候 怖 的 
MissingBackpressureException。zip() (和 zipWwith()) 操作 符 并 不 会 不 顾 上 游 的 吞吐 量 育 
目地 接收 事件 。 相 反 ， 这 些 操作 符 会 使 用 回 压 (参见 6.2 节 )， 并 且 只 请 求 尽 可 能 少 的 数 
据 。 因 此 ， 如 果 上 游 0bservable 是 cold 类 型 的 ， 并 且 实 现 得 比较 好 ，zip() 会 减缓 较 快 的 
Observable。 这 是 通过 请 求 少量 的 数据 实现 的 ， 而 该 observable 在 技术 上 本 来 能 够 生成 更 
而 interval() 的 运行 机 制 有 所 不 同 。interval() 操作 符 是 cold 类 型 的 ， 只 有 有 人 订阅 的 
时 候 才 会 开始 计数 ， 而 且 每 个 0bserver 都 会 得 到 独立 的 流 。 但 是 在 订阅 interval() 之 后 ， 
我 们 无 法 减缓 它 的 速度 ， 按 照 定义 ， 它 必须 按照 固定 的 频率 发 布 事件 。 因 此 ， 它 必须 忽略 
回 压 请 求 ， 这 可 能 会 导致 上 LssingBackpressureException。 我 们 能 做 的 就 是 丢弃 多 余 的 习 
件 (参见 6.2.3 节 )。 


Observable 
.Zip( 






































二 








fast.onBackpressureDrop()， 

slow.onBackpressureDrop(), 

(f, s) -> f+":"+s) 
MissingBackpressureException 又 比 0utofMemoryError 好 在 哪里 呢 ? 缺失 回 压 会 立即 失败 ， 
而 内 存 不 足 则 可 能 会 缓慢 累积 ， 消 耗 本 该 分 配 到 其 他 地 方 的 宝贵 内 存 。 但 是 ,缺失 回 压 功 
能 的 异常 也 可 能 在 最 意 想不到 的 时 刻 发 生 ， 比 如 在 垃圾 收集 的 时 候 。7.3 节 讨 论 了 如 何 对 
回 压 行为 进行 单元 测试 。 


8.7 小结 


如 果 我 们 的 代码 中 已 经 有 了 一 些 Observable 源 ， 开 始 使 用 RxJava 就 会 容易 得 多 。 从 头 实 
现 新 的 observable 非常 容易 出 错 ， 所 以 当 各 种 库 (如 Hystrix,、Retrofit、 数 据 库 驱动 ) 提 
供 了 对 RxJava 的 原生 支持 后 ， 使 用 RxJava 就 简单 多 了 。 在 4.1 节 中 ， 我 们 非常 缓慢 地 将 
一 个 已 有 的 应 用 程序 从 命令 式 、 面 向 集合 的 风格 重 构 为 面向 流 、 声 明 式 的 方式 。 但 是 在 引 
入 支持 异步 0bservabte 源 的 库 之 后 ， 重 构 就 简单 多 了 。 应 用 程序 中 的 流 越 多 ， 反 应 式 API 
就 能 向 上 传播 地 越 广 。 从 数据 获取 层 (数据 库 、Web 服务 等 ) 开始 ， 然 后 扩展 至 服务 层 和 
Web 层 ， 突 然 之 间 ， 我 们 会 发 现 整个 技术 栈 都 是 反应 式 的 。 从 某 种 程度 上 来 说 ，RxJava 的 
使 用 在 项 目 中 达到 一 个 临界 点 之 后 ， 就 不 再 需要 toBLocking() 了 ， 因 为 从 头 到 尾 ， 所 有 的 
事情 都 变 成 了 流 。 

































































注 5: 在 RxJava 中 引入 回 压 前 , zip() 就 是 这 样 工作 的 。 我 们 很 容易 遇 到 异步 的 流 , 这 会 导致 缓慢 的 内 存 泄漏 。 
如 果 想 了 解 zip() 是 如 何 重新 实现 的 ， 那 么 需要 在 0.20-RC2 版 本 中 首先 添加 回 压 。 
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未 来 的 方向 





本 . 克 里 斯 滕 森 〈Ben Christensen ) 


在 锁定 1.0 版 本 的 API 之 前 ，RxJava 在 0x 版 本 上 阶段 花费 了 很 多 时 间 ， 所 以 这 是 一 个 非 
常 成 熟 和 稳定 的 版 本 。 同 时 ， 由 于 我 们 决定 支持 API 上 的 Experimental 和 Beta 标记 ， 在 将 
API 提升 至 Final 之 前 ,一 些 正在 进行 中 的 实验 性 功能 还 会 继续 开展 。 但 是 ，0.x/1.x 阶段 中 
的 一 些 决策 依然 存在 具有 破坏 性 的 缺陷 ， 所 以 2.0 版 本 正在 开发 中 。 

基本 上 ， 它 与 1x 非常 相似 ， 所 以 不 管 在 思想 上 还 是 用 法 上 都 不 会 有 太 大 的 变更 。 即 便 2.0 
版 本 已 经 发 布 ， 本 书 介绍 的 大 部 分 内 容 依然 有 效 。 那 么 为 什么 要 开发 2.0 版 本 呢 ? 


9.1 反应 式 流 


第 一 个 原因 是 原生 支持 反应 式 流 API。 尽 管 RxJava 团队 参与 了 反应 式 流 的 制订 ,但 是 
RxJava vl 的 API 已 经 被 锁定 ， 因 此 我 们 无 法 进行 修改 以 适应 反应 式 流 中 的 接口 。 尽 管 
RxJava v1 在 语义 上 的 行为 与 反应 式 流 非 常 相似 ， 但 是 它 需 要 一 个 适配器 。2.0 版 本 会 直接 实 
现 反 应 式 流 的 类 型 并 完全 符合 规范 ， 以 便 更 好 地 支持 Java 社区 的 互 操作 性 。 


9.2 Observable 和 Flowable 


另外 一 个 原因 是 将 Observable 类 型 分 成 了 两 个 类 型 : 0bservable 和 Flowable。 让 一 切 都 支 
持 回 压 是 错误 的 ， 并 不 是 所 有 的 用 例 都 需要 该 特性 。 它 的 性 能 消耗 很 小 ， 说 它 是 一 个 错误 
的 主要 原因 在 于 : 它 大 幅 增 加 了 使 用 0bservable 和 创建 自 定 义 操作 符 的 难度 。 

单纯 的 推送 场景 应 该 按照 Erik Meijer 最 初 设计 的 那样 使 用 Observable， 即 不 具备 反应 式 流 
的 request(n) 语义 。 这 样 的 用 例 非常 普遍 。 基 本 上 ， 所 有 的 用 户 界面 (user interface，UI) 
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用 例 (比如 在 Android 中 ) 都 是 纯 推 送 的 。 在 这 种 场景 下 ， 使 用 request(n) 会 令 人 产生 困 
惑 ， 增 加 不 必要 的 复杂 性 。 这 时 ，onBackpressureDrop 风格 的 操作 符 可 能 会 非常 有 用 ， 但 
是 应 该 有 选择 性 地 加 入 进来 。 


因此 ， 在 v2 版 本 中 ， 如 果 是 单纯 的 推送 ， 不 支持 request(n) 就 应 该 返回 0bservable， 它 
“会 实现 反应 式 流 的 类 型 或 规范 。 同 时 ，v2 版 本 新 增加 了 一 个 类 型 Flowable， 它 是 “具备 
回 压 的 Observable”， 实 现 了 反应 式 流 的 Publisher 类 型 和 规范 。 将 其 命名 为 “Flowable” 
是 受 Javag9 的 java.util.concurrent.Flow 的 启发 ， 后 者 采用 了 反应 式 流 接口 。 


有 了 0bservable 和 Flowable 之 后 ， 就 能 够 更 好 地 在 公开 API 交流 该 数据 源 的 行为 是 什么 。 
如 果 是 0bservable， 它 支持 推送 ， 消 费 者 必须 已 经 准备 就 绕 ， 如 果 是 Flowable， 它 执行 拉 
取 一 推送 模式 ， 只 会 发 送 消 费 者 请 求 数量 的 条 目 。 类 似 于 RxJava v1 中 做 的 那样 ， 它 们 两 
者 之 间 也 可 以 转换 ， 不 过 此 时 的 转换 会 更 加 明确 ， 比 如 observable.toFlowable(Strategy. 
DROP)。 这 样 就 会 将 0bservable 转换 为 具有 对 应 回 压 策略 的 Flowable， 如 果 数 据 的 推送 速 
度 比 消费 者 的 处 理 速度 更 快 ， 会 应 用 该 策略 。 


9.3 性 能 

开发 v2 版 本 的 最 后 一 个 主要 原因 是 提升 整体 的 性 能 (减少 资源 消耗 )， 从 而 规避 vl 版 本 
的 架构 限制 。 这 在 一 定 程度 上 是 通过 减少 在 构建 操作 符 链 、 订 阅 和 运行 它们 时 分 配 的 数 
量 实现 的 。 上 默认 情况 下 ，Subscriber 不 会 再 包装 到 一 个 Safesubscriber 中 (为 此 提供 了 
Flowable.safeSubscribe()),， 终端 事件 上 也 不 再 需要 通过 cancel (在 v2 版 本 的 语义 中 ， 
对 应 的 是 unsubscribe) 取消 这 个 链 。 

性 能 改进 的 第 二 个 来 源 是 一 种 内 部 优化 方法 ， 称 为 操作 符 融 合 (operator-fusion， 它 扩展 了 
反应 式 流 协议 )。 在 很 多 同步 流 的 环境 中 ， 它 能 够 大 幅 减 少 回 压 和 队列 管理 的 消耗 (在 某 
些 异 步 流 中 也 能 达到 该 效果 )。 在 一 些 基 准 测 试 中 ， 开 局 了 回 压 功能 的 流 在 吞吐 量 上 仅 比 
Java 8 的 Stream (是 同步 拉 取 的 ) 实现 慢 20%~30%， 而 在 v1 版 本 中 要 慢 100%~200%。 


9.4 迁移 


由 于 RxJava 在 应 用 程序 中 影响 较 大 ， 难 以 接受 破坏 性 的 变更 。 因 此 ，v2 版 本 使 用 了 不 同 
的 包 名 和 Maven artifact ID ( 表 9-1)， 这样 vl 和 v2 版 本 在 同一 个 项 目 中 就 能 够 共存 了 。 































































































表 9-1 
v1 的 包 v2 的 包 v1 的 Maven v2 的 Maven 
TX io.reactivex.* io.reactivex:rxjava io.reactivex.rxjava2:rxjava 


从 RxJava 的 vl 版 本 切换 至 v2 版 本 主要 涉及 如 下 工作 。 


(1) 将 包 名 从 rx. 替换 成 io.reactivex。 
(2) 如 果 需 要 回 压 功能 ， 将 0bservable 替换 为 Flowable。 


RxJava v2 位 于 GitHub 的 2.x 分 支 ， DESIGN.md 文档 介绍 了 社区 设计 v2 版 本 时 在 技术 决 
策 方面 做 出 的 努力 。 关 于 v1 和 v2 版 本 差异 的 更 多 信息 可 以 在 GitHub 上 找到 。 
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HTTP 服 务 器 的 更 多 样 例 








附录 A 对 5.1 节 的 内 容 进 行 了 扩展 ， 提 供 了 更 多 的 HTTP 服务 器 样 例 。 这 些 样 例 对 于 理解 
第 5 章 的 内 容 并 不 是 必需 的 ， 但 是 我 们 可 能 会 发 现 它们 的 有 趣 之 处 。 另 外 ， 这 些 样 例 中 的 
一 部 分 也 包含 在 了 基准 测试 中 。 


A.1 C 语 言 中 的 fork() 程 序 


我 们 尝试 使 用 C 语言 实现 一 个 并 发 HTTP 服务 器 。 如 果 你 熟悉 C 语言 ， 会 发 现 如 下 的 程序 
非常 简单 。 如 果 不 熟悉 也 不 用 担心 ， 你 不 必 了 解 全 部 的 细节 ， 和 掌握 整 体 的 理念 即 可 。 调 用 
fork() 会 生成 当前 进程 的 一 个 副本 ， 以 至 于 在 操作 系统 中 会 突然 出 现 两 个 进程 : 原始 的 进 
程 〈 父 进程 ) 和 子 进程 。 第 二 个 进程 具有 完全 相同 的 变量 和 状态 ， 唯 一 的 差异 是 fork() 的 
结果 值 。 

#include <signal.h> 

#include <stdlib.h> 

#include <string.h> 

#include <netinet/in.h> 


#include <unistd.h> 
#include <stdio.h> 















































int main(int argc, char *argv[]) { 
signal(SIGCHLD, SIG_IGN); 
struct sockaddr_in serv_addr; 
bzero((char *) &serv_addr, sizeof(serv_addr)); 
serv_addr.sin family = AF_INET; 
serv_addr .sin addr.s_addr = INADDR_ANY; 
serv_addr.sin port = htons(8080); 
int server_socket = socket(AF_INET, SOCK_STREAM, 0); 
if(server_socket < 0) { 


263 


perror("socket"); 
exit(1); 


if(bind(server_socket, 
(struct sockaddr *) &serv_addr, 
sizeof(serv_addr)) < 0) { 
perror("bind"); 
exit(1); 
} 
listen(server_socket, 100); 
struct sockaddr_in cli addr; 
socklen _t clilen = sizeof(cli addr); 
while (1) { 
int client_socket = accept( 
server_socket, (struct sockaddr *) &cli addr, &clilen); 
if(client socket < 0) { 
perror("accept"); 
exit(1); 
} 
int pid = fork(); 
if (pid == 0) { 
close(server_socket); 
char buffer[1024]; 
while(1) { 
if(read(client_socket,buffer,255) < 0) { 
perror("read"); 
exit(1); 
} 
if(write(client_socket, 
"HTTP/1.1 200 OK\r\nContent-length: 2\r\n\r\nok", 
40) < 0) { 
perror("write"); 
exit(1); 
} 
} 
} else { 
if(pid < 0) { 
perror("fork"); 
exit(1); 


} 


close(client_ socket); 


} 


return 0; 


} 


真正 重要 的 是 对 fork() 的 调用 。 在 父 进程 (原始 进程 》 中 ， 它 返回 了 子 进程 的 PID (进程 
ID) ; 在 子 进程 (副本 进程 ) 中 ， 它 返回 的 是 9。 在 某 些 情况 下 ，fork() 只 执行 一 次 (在 
父 进 程 中 )， 但 是 会 返回 两 次 。 如 果 发 现 自己 是 子 进程 (fork() == 9)， 那 么 就 需要 处 理 客 
户 端 连接 。server_socket 由 父 进 程 管 理 ， 可 以 在 子 进程 中 关闭 。 同 时 (并 发 地 )， 父 进程 
关闭 client_socket ( 子 进程 依然 使 其 处 于 打开 状态 )， 并 且 能 够 通过 accept() 接收 其 他 客 
户 端 连接 。 当 然 ， 父 线程 可 以 同时 派生 (fork) 多 个 子 线程 ， 以 实现 更 高 的 并 发 性 。 
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A.2 每 个 连接 对 应 一 个 线程 








既然 一 个 线程 难以 很 好 地 扩展 服务 器 (参见 5.1.1 节 )， 那 么 我 们 就 采取 一 些 线程 技术 对 其 














进行 重 写 。 在 进入 实现 细节 之 前 ， 我 们 先 重 写 一 下 SingleThread 类 ， 避 免 在 后 续 样 例 中 重 








复出 现 。 
abstract class HttpServer { 


void run(int port) throws IOException { 
final ServerSocket serverSocket = new ServerSocket(port, 100); 
while (!Thread.currentThread().isInterrupted()) { 
final Socket client = serverSocket.accept(); 
handle(new ClientConnection(client)); 


} 


abstract void handle(ClientConnection clientConnection); 


} 
ClientConnection 类 如 下 所 示 。 
import org.apache.commons.io.IOUtils; 
class ClientConnection implements Runnable { 
public static final byte[] RESPONSE = ( 

"HTTP/1.1 200 OK\r\n" + 
"Content-Length: 2\r\n" + 
"\r\n" 本 
"OK").getBytes(); 


public static final byte[] SERVICE_UNAVAILABLE = ( 
"HTTP/1.1 503 Service unavailable\r\n").getBytes(); 


private final Socket client; 


ClientConnection(Socket client) { 
this.client = client; 


} 
public void run() { 
try { 
while (!Thread.currentThread().isInterrupted()) { 
readFullRequest(); 
client.getOutputStream() .write(RESPONSE) ; 
} 


} catch (Exception e) { 
e.printStackTrace(); 
IOUtils.closeQuietly(client); 


} 


private void readFullRequest() throws IOException { 
BufferedReader reader = new BufferedReader( 
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new InputStreamReader(client.getInputStream())); 
String Line = reader.readLine(); 
while (line != null && !line.isEmpty()) { 
line = reader.readLine(); 


} 
} 


public void serviceUnavailable() { 


try { 
client.getOutputStream().write(SERVICE_UNAVAILABLE); 


} catch (IOException e) { 
throw new RuntimeException(e); 


} 


} 
这 只 是 一 个 简单 的 重 构 : 我 们 将 一 些 通用 的 样板 代码 (比如 在 循环 中 监听 客户 端的 连接 ) 
转移 到 基 类 。 同 时 ， 将 处 理 客户 端 连接 的 功能 放 到 一 个 单独 的 ClientConnection 类 中 ， 随 
后 使 用 一 个 额外 的 serviceUnavailable()。Httpserver 实现 的 唯一 责任 就 是 以 某 种 方法 调 
用 ClientConnection 的 run()， 例 如 在 重 构 后 的 SingleThread 中 直接 进行 调用 。 


public class SingleThread extends HttpServer { 

















public static void main(String[] args) throws Exception { 
new SingleThread().run(8080); 
} 


@Override 
void handle(ClientConnection clientConnection) { 


clientConnection.run(); 


} 
} 


有 了 基础 框架 (framework) ， 我 们 就 可 以 快速 构建 更 具 扩 展 性 的 实现 ， 这 种 实现 方式 会 为 
每 个 ClientConnection 生成 一 个 新 的 Thread。 





public class ThreadPerConnection extends HttpServer { 


public static void main(String[] args) throws IOException { 
new ThreadPerConnection().run(8080); 


} 


@Override 
void handle(ClientConnection clientConnection) { 
new Thread(clientConnection).start(); 


} 
} 
利用 ClientConnection 也 是 Runnable 这 个 事实 ， 样 例 为 每 个 新 连接 只 启动 了 一 个 Thread。 
现在 ， 服 务 器 被 缓慢 的 客户 端 阻塞 的 问题 得 到 了 缓解 对 连接 的 处 理 在 后 台 发 生 。 这 样 ， 
当 针 对 客户 端 socket 读 取 和 写 入 数据 时 ， 主 线程 依然 能 够 接收 新 的 连接 。 当 然 ， 如 果 同 时 
有 两 个 客户 端 连接 ， 主 线程 会 启动 两 个 后 台 线 程 并 继续 后 面 的 操作 。 
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毫 无 限制 地 创建 新 线程 也 有 一 些 缺 点 。 在 64 位 的 JVM 1.8 上 ， 每 个 线程 默认 消耗 RAM 上 
1024 KB 的 空间 (参见 -Xss 标记 )。 如 果 有 上 千 个 并 发 连接 ， 即 便 它们 是 空 闪 的 ， 也 意味 
着 会 有 1000 个 线程 和 1 GB 的 栈 空间 。 不 要 混淆 ， 栈 空间 独立 于 堆 空 间 ， 所 以 应 用 程序 消 
耗 的 内 存 远 超过 1 GB。 


A.3 连接 的 线程 池 


这 次 创建 一 个 由 空闲 线程 组 成 的 了 地， 让 它 等 待 传人 的 连接 。 包 装 了 客户 端 Socket 的 新 
ClientConnection 出 现时 ， 我 们 会 使 用 池 中 第 一 个 空闲 线程 。 相 对 于 按 需 创建 线程 ， 线 程 
池 的 方式 有 以 下 优点 。 


。 Thread 已 经 初始 化 和 启动 完成 ， 因 此 不 必 等 待 或 预 热 ， 减 少 了 客户 端的 延迟 。 

。 系统 中 的 线程 总 数 有 严格 限制 ， 因 此 在 高 峰 人 负载 时 可 以 安全 地 拒绝 连接 ， 而 不 会 引起 系 
统 骨 涡 。 

。 线程 池 有 一 个 可 配置 的 队列 ， 可 以 临时 存放 短期 高 峰 时 的 负载 。 

。 如 果 池 和 队列 都 已 经 饱和 ， 那 么 还 可 以 使 用 一 个 可 配置 的 拒绝 策略 (报错 ， 转 而 在 客户 
端 线程 中 运行 等 )。 

如 果 想 完全 控制 正在 创建 的 线程 ， 那 么 相对 于 每 次 都 创建 新 线程 ， 线 程 池 是 一 种 更 好 的 方 

式 。 更 重要 的 是 ， 我 们 可 以 严格 控制 客户 端 线程 的 总 数 ， 并 且 管 理 峰 值 状态 。 


class ThreadPooL extends HttpServer { 
























































private final ThreadPoolExecutor executor; 


public static void main(String[] args) throws IOException { 
new ThreadPool().run(8080); 
} 


public ThreadPool() { 
BlockingQueue<Runnable> workQueue = new ArrayBlockingQueue<>(1000); 
executor = new ThreadPoolExecutor(100, 100, OL, 
MILLISECONDS, workQueue, 
(r, ex) -> { 
((ClientConnection) r).serviceUnavailable(); 
]); 
} 


@Override 
void handle(ClientConnection clientConnection) { 
executor .execute(clientConnection); 


} 
} 
需要 处 理 ClientConnection 的 上 时候， 我 们 可 以 将 这 个 任务 移交 给 专门 的 ThreadPooLExecutor， 
它 在 内 部 管理 100 个 线程 。 在 这 个 池 的 前 面 有 一 个 有 界 的 队列 (1000 个 任务 ) ， 在 出 现 大 量 请 
求 时 ，RejectedExecutionHandtLer 就 会 发 挥 作用 。 服 务 器 会 简单 地 调用 serviceUnavailable()， 
并 立即 为 客户 端 返回 503 (快速 失败 行为 ， 参 见 8.2 节 )， 而 不 是 让 客户 端 无 休止 地 等 待 。 
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借助 Servlet 3.0 规范 ， 我 们 能 够 基于 异步 Servlet 编写 可 扩展 的 应 用 程序 。 它 的 理念 是 将 请 
求 的 处 理 和 容器 线程 进行 解 耦 。 当 请 求 需要 发 送 响应 时 ， 它 可 以 在 任何 时 间 点 的 任何 线程 
中 发 送 。 而 接收 请 求 的 原始 容器 线程 可 能 已 经 消失 ， 或 在 处 理 其 他 请 求 。 这 是 一 个 革命 性 
的 理念 ， 但 是 应 用 程序 的 其 他 部 分 也 必须 按照 这 种 方式 进行 构建 。 否 则 ， 应 用 程序 可 能 会 
更 具 响 应 性 (容器 线程 池 很 少 会 饱和 )。 但 是 如 果 必 须 有 另外 的 用 户 线程 处 理 该 请 求 ， 那 
么 只 是 将 线程 暴 增 的 问题 转移 到 了 其 他 地 方 而 已 。 线 程 数量 达到 数 百 其 至 数 千 的 时 候 ， 应 
用 程序 的 行为 就 会 出 现 异常 ， 例 如 ， 由 于 频繁 的 垃圾 收集 循环 和 上 下 文 切 换 ， 它 的 响应 变 
得 越 来 越 慢 。 
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附录 B 





0bservable 操 作 符 的 决策 树 


本 附录 旨 在 帮助 你 从 RxJava 中 找到 合适 的 操作 符 。 我 们 有 上 百 个 可 选项 ， 找 到 最 适合 
需求 的 内 置 操 作 符 会 变 得 越 来 越 复杂 。 附 录 的 内 容 完 全 复制 自 RxJava 官方 文档 ， 这 个 
Observable 操作 符 决 策 树 文档 基于 Apache 2.0 许可 证 。 但 是 ， 接 下 来 的 反 向 引用 指 的 是 本 
书 中 的 章节 ， 而 不 是 在 线 文档 。 大 多 数 给 定 操作 符 都 有 一 个 完整 的 章节 ， 有 些 操作 符 只 进 
行 简单 的 介绍 或 提供 一 个 样 例 。 


我 想 要 创建 一 个 新 的 0bservable…… 























想 要 发 布 特定 的 条 目 ， 使 用 just()， 参 见 2.4 市 …… 

4 想 要 在 订阅 的 时 候 , 从 一 个 函数 返回 内 容 , 使 用 start(), 参见 rxjava-async 模块 。 

4 要 要 在 订阅 的 时 候 ， 通 过 Action、Callable 或 Runnable 等 返回 内 容 ， 使 用 
from()、fromCallable() 或 fromRunnable()， 参见 2.4 节 和 2.4.2 节 。 

4 在 特定 的 延迟 后 生成 ， 使 用 timer()， 参 见 2.4.3 市 。 

想 要 从 特定 的 Array、Iterable 等 发 布 内 容 ， 使 用 from()， 参 见 2.4 布 。 

想 要 从 Future 获取 内 容 ， 使 用 from()， 参 见 2.4 节 和 5.4 节 。 

想 要 从 Future 获取 序列 ， 使 用 from()， 参 见 2.4 节 。 

想 要 重复 性 地 发 布 条 目 序列 ， 使 用 repeat()， 参 见 3.5.1 市 。 

















想 要 从 头 开始 使 用 自 定义 的 逻辑 发 布 内 容 ， 使 用 create()， 参 见 2.4.1 市 。 
想 要 为 订阅 的 每 个 观察 者 发 布 内 容 ， 使 用 defer()， 参 见 4.3 节 。 
想 要 发 布 整数 序列 ， 使 用 range()， 参 见 2.4 节 ……… 
4 想 要 按照 特定 的 时 间 间 隔 生 成 ,使 用 interval()， 参 见 2.4.3 节 。 
a 在 特定 延迟 之 后 生成 ,使 用 timer()， 参 见 2.4.3 节 。 
想 要 不 发 布 任何 条 目 就 结束 ， 使 用 empty()， 参 见 2.4 市 。 
想 要 0bservable 什么 事情 都 不 做 ， 使 用 never()， 参 见 2.4 节 。 





4 
4 
4 
a 
4 
4 











我 想 要 通过 联合 其 他 0bservable 的 方式 创建 0Observable…… 
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一 想 要 将 所 有 0bservable 的 条 目 按照 接收 到 的 顺序 发 布 ， 使 用 merge()， 参 见 3.2.1 节 。 

一 想 要 将 所 有 0bservable 的 条 目 都 发 布 出 去 , 但 是 每 次 只 发 布 一 个 0bservable 的 条 目 ， 
使 用 concat()， 参 见 3.4.1 市 。 

- 想 要 将 两 个 或 更 多 0bservable 中 的 条 目 顺序 地 组 合 在 一 起 生成 新 条 目 ， 并 且 发 布 该 














4 无 论 何 时 每 个 0bservable 都 发 布 了 一 个 新 条 目 ， 使 用 zip()， 参 见 3.2.2 节 。 
* 无 论 何 时 任意 一 个 Observable 发 布 一 个 新 条 目 , 使 用 combineLatest(), 参见 3.2.3 节 。 
4 通过 Pattern 和 Plan 的 中 介 ad 参见 rxjava-joiins 模块 。 
一 只 从 最 近 发 布 的 一 个 Observable 中 发 布 条 目 ， 使 用 switch()， 参 见 3.4.1 节 。 
我 想 要 将 Observable 中 的 条 目 转换 之 后 ， 
一 以 调用 函数 的 形式 ， 使 用 map()， 参 见 3.1 节 。 
一 通过 对 应 0bservablte 发 布 所 有 条 更 用 fLatMap() ， 人 参见 3.1.2 节 。 
4 每 次 生成 一 个 0bservable, 按 和 的 顺序 进行 排列 , 使 用 concatMap(), 参见 3.1.5 节 。 
一 基于 它们 前 面 的 所 有 和 条目， 使 用 scan()， 参 见 3.3.1 节 。 
- 通过 为 条 目 附加 一 个 时 间 疏 ， 使 用 timestamp()， 参 见 3.2.3 市。 
- 转换 为 一 个 指示 器 ， 表 明 该 条 目 发 布 之 前 已 经 消耗 的 时 间 ， 使 用 timeInterval()， 
参见 7.1.3 节 。 
我 想 要 将 Observable 发 布 的 条 目 及 时 转发 后 ， 使 用 delay(), 参见 3.1.3 节 。 
我 想 要 将 Observable 中 的 条 目 和 通知 转换 为 条 目 并 重新 发 布 …… 
一 使 用 materialize() 将 其 包装 到 Notification 对 和 象 中 ， 参 见 7.3 节 。 
4 使 用 dematerialize() 再 次 进行 拆 解 。 
我 想 要 忽略 0bservable 发 布 的 所 有 条 目 ， 只 向 下 传播 完成 /错误 通知 ,使 用 ignoreElements()， 









































参见 4.6 节 。 
我 想 要 得 到 0bservable 的 镜像 ， 但 是 在 真正 的 序列 之 前 添加 一 些 条 目 ， 使 用 startwith()， 
参见 3 3 区 节 … 


一 仅 当 observablte 为 空 时 ， 才 添加 这 些 条 目 ， 使 用 defauLtIfEmpty()。 

我 想 要 收集 某 个 observable 的 所 有 条 目 ， 并 以 缓冲 的 方式 重新 发 布 ， 使 用 buffer()， 

参见 8.6 节 。 

一 只 想 包含 最 后 发 布 的 一 些 条 目 ， 使 用 takeLastBuffer()。 

我 想 要 将 一 个 0bservable 分 割 为 多 个 Observable,， 使 用 window()， 参 见 6.1.3 节 。 

一 想 要 将 相似 的 条 目 最 终 放 到 同一 个 0Observable， 使 用 groupBy()， 参 见 3.4.2 节 。 

我 想 要 检索 0bservable 发 布 的 一 些 特定 条 目 …… 

一 0 ， 使 用 Last()， 参 见 3.4 节 。 

一 想 要 发 布 的 唯一 ， 使 用 single()， 参见 3.3.3 节 。 

一 和 使 用 first()， 参 见 3.4 节 。 

我 想 要 重新 发 布 Observable 中 的 特定 条 目 …… 
过 滤 不 符合 指定 断言 的 条 目 ， 使 用 filter()， 参见 3.1 节 。 

一 只 要 第 一 个 条 目 ， 使 用 first()， 参 见 3.4 市 。 

一 只 要 前 几 个 条 目 ， 使 用 take()， 参 见 3.4 市 。 

一 只 要 最 后 一 个 条 目 ， 使 用 Last()， 参 见 3.4 节 。 

一 只 要 排序 为 n 的 条 目 ， 使 用 elementAt()， 参 见 3.4 节 。 
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只 要 前 几 个 条 目 之 后 的 给 定 条 目 …… 

跳 过 前 n 个 条 目 ， 使 用 skip()， 参 见 3.4 节 。 

直到 其 中 的 一 个 条 目 符合 指定 的 断言 ， 使 用 skipwhite()， 参 见 7.1.3 节 。 
获取 初始 的 时 间 段 之 后 的 条 目 ， 使 用 skip()。 

第 二 个 Observable 之 后 开始 发 布 条 目 ， 使 用 skipUntiL() 。 

想 要 得 到 最 后 这 些 条 目 之 外 的 其 他 条 目 …… 

不 想 要 最 后 的 n 个 条 目 ， 使 用 skipLast()， 参 见 3.4 节 。 

直到 其 中 的 一 个 条 目 符合 指定 的 断言 ， 使 用 takewhite()， 参 见 3.4 市 。 
不 想 要 源 完 成 之 前 那 段 时 间 内 的 条 目 ， 使 用 skipLast()。 

不 想 要 第 二 个 Observable 发 布 的 条 目 之 后 的 所 有 条 目 ， 使 用 takeUntitL() 。 
想 要 对 0bservable 进行 周期 性 采样 ， 使 用 sample()， 参 见 6.1.1 市 。 

只 想 要 发 布 条 目 间隔 时 间 不 在 一 定时 间 范 围 内 的 事件 ,使 用 debounce(), 参 见 6.1.4 节 。 
想 要 跳 过 已 发 布 的 重复 条 目 ， 使 用 distinct()， 参见 3.3.4 节 ……… 

4 想 要 跳 过 紧邻 的 重复 条 目 ， 使 用 distinctuntilChanged()， 参 见 3.3.4 节 。 
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一 想 要 在 Observable 发 布 条 目 之 后 ， 延 迟 对 它 的 订阅 ， 使 用 delaySubscription()。 
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附录 C 
RxJava 1.0 至 RxJava 2.0 的 迁移 指南 








在 翻译 本 书 时 ，RxJava 2.0 已 经 推出 ， 且 RxJava 1.0 已 终止 维护 。 尽 管 RxJava 1.0 与 
RxJava 2.0 在 理念 上 一 脉 相 承 ， 但 RxJava 2.0 完全 是 重新 编写 的 ， 所 以 在 一 些 具体 用 法 上 
会 有 较 大 的 差异 。 因 此 ， 经 许可 ， 译 者 翻译 了 GitHub 上 关于 RxJava 1.0 与 RxJava 2.0 差 
异 的 两 篇 文章 ， 供 读者 阅读 参考 。 这 两 篇 文章 的 作者 是 RxJava 2.0 的 核心 贡献 者 和 负责 人 
David Karnok。 其 中 ， 第 一 篇 文章 概要 阐述 了 两 个 版 本 的 差异 ， 第 二 篇 文章 主要 前述 了 在 
RxJava 2.0 版 本 中 如 何 使 用 回 压 功 能 。 


C.1 RxJava 2.0 版 本 的 变化 


RxJava 2.0 是 在 反应 式 流 规范 之 上 完全 重 写 的 。 这 个 规范 本 身 从 RxJava 1x 发 展 而 来 ， 为 
反应 式 流 和 库 提供 了 一 个 通用 的 基准 。 


因为 反应 式 流 具 有 不 同 的 架构 ， 所 以 需要 对 一 些 众 所 周知 的 RxJava 类 型 做 出 变更 。 本 文 
会 尝试 总 结 这 些 变更 ， 并 描述 如 何 将 RxJava 1.x 的 代码 重 写 为 RxJava 2.x 的 代码 。 


关于 2.x 编写 操作 符 的 更 多 技术 细节 ， 请 参阅 GitHub 上 的 文章 Writing Operators。 


C.1.1 Maven 地 址 和 基础 包 


为 了 让 RxJava 1.x 和 RxJava 2.x 共存 ，RxJava 2.x 的 Maven 坐标 为 io.reactivex.rxjava2: 
rxjava:2.x.y， 类 则 位 于 io.reactivex 包 下 。 


要 想 从 RxJava 1.x 切换 至 RxJava 2.x， 需 要 重新 组 织 导入 语句 ， 不 过 要 小 心 一 些 。 












































C.1.2 Javadoc 
针对 2.x 的 Javadoc 页 面 现 在 托管 在 http://reactivex.io/RxJava/2.x/javadoc/ 中 。 
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C.1.3 关于 nuLL 


RxJava 2.x 不 能 接受 nutLt 值 。 因 此 ， 如 下 代码 会 立即 抛 出 NuLLPointerException， 或 者 作 
为 错误 信号 传递 到 下 游 中 。 


Observable.just(null); 














Single.just(null); 


Observable.fromCallable(() -> null) 
.Subscribe(System.out::println, Throwable::printStackTrace); 


Observable.just(1).map(v -> null) 
.Subscribe(System.out::println, Throwable::printStackTrace); 


这 意味 着 Observable<Void> 不 会 发 布 任何 值 ， 只 能 正常 终止 或 者 以 异常 的 方式 终止 。API 
设计 者 反而 可 以 选择 将 API 定义 为 Observable<0bject>, 但 是 这 样 将 无 法 对 0bject 的 内 容 
提供 保证 (不 过 ， 应 该 关系 不 大 )。 例 如 ， 如 果 需 要 类 似 信号 的 源 ， 那 么 可 以 定义 一 个 共 
享 的 枚 举 并 在 onNext 中 使 用 该 单 实例 的 枚 举 值 。 


enum Irrelevant { INSTANCE; } 

















Observable<Object> source = Observable.create((ObservableEmitter<0bject> emitter) -> { 
System.out.println("Side-effect 1"); 
emitter.onNext(Irrelevant.INSTANCE); 


System.out.println("Side-effect 2"); 
emitter.onNext(Irrelevant.INSTANCE); 


System.out.println("Side-effect 3"); 
emitter.onNext(Irrelevant.INSTANCE); 
]); 


source.subscribe(e -> { /* Ignored. */ }, Throwable::printStackTrace); 


C.1.4 0bservabLe 和 FLowabtLe 

在 RxJava 0x 中 引入 回 压 有 一 个 小 遗憾 ， 即 没有 创建 单独 的 反应 式 基 础 类 ， 而 是 直接 改造 
了 Observable 本 身 。 回 压 的 主要 问题 在 于 很 多 hot 类 型 的 源 (比如 UI 事件 ) 不 能 合理 地 
添加 回 压 功 能 ， 因 此 会 造成 MissingBackpressureException。 

2x 版 本 试图 弥补 这 一 点 ， 同 时 提供 了 不 支持 回 压 的 io.reactivex.0bservable 以 及 支持 回 
压 的 新 反应 式 基础 类 io.reactivex.Flowable。 

好 消息 是 操作 符 的 名 称 (大 部 分 ) 都 保持 了 一 致 ， 坏 消息 是 组 织 导入 语句 时 要 十 分 小 心 ， 
因为 有 可 能 会 导入 不 支持 回 压 的 io.reactivex.0bservable。 

使 用 哪 种 类 型 

在 对 数据 流 进行 架构 设计 (作为 RxJava 的 终端 消费 者 )， 或 者 编写 兼容 RxJava 2.x 版 
本 库 的 代码 时 ， 如 果 需 要 决定 使 用 和 返回 的 类 型 ， 那 么 可 以 考量 一 些 因 素 ， 避 免 出 现 
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MissingBackpressureException 或 0utOfMemoryError 这 样 的 问题 。 


口 人 Observable 
如 果 流 的 最 大 长 度 不 超过 1000 个 元 素 , 也 就 是 说 , 随 着 时 间 的 推移 , 元 素 的 数量 很 
应 用 程序 基本 上 不 会 出 现 OOME 错误 。 
如 果 处 理 的 是 GUI 事件， 比如 鼠标 移动 或 触摸 事件 : 这 些 事 件 很 少 能 合理 地 实现 回 
压 功能 ， 而 且 它 们 的 出 现 频率 不 会 很 高 。 借 助 Observable， 能 够 处 理 频 率 为 1000 Hz 
或 更 低 的 元 素 ， 但 是 可 以 考虑 使 用 采样 /去 除 抖动 的 策略 。 
如 果 你 的 流 在 本 质 上 是 同步 的 ， 但 是 平台 不 支持 Java Stream 或 者 不 能 使 用 某 些 特 
性 。 使 用 0bservable 的 开销 一 般 比 Flowable 低 一 些 (也 可 以 考虑 使 用 IxJava， 它 对 
Iterable 流 进行 了 优化 ， 支 持 Java 6+)。 

口 Flowable 
要 处 理 的 元 素数 量 超过 10 000 个 ， 因 此 能 够 告诉 源 限制 生成 的 元 素数 量 。 
从 磁盘 读 取 (解析 ) 文件 本 质 上 是 阻塞 的 ， 并 且 是 基于 拉 取 模式 的 。 它 能 够 很 好 地 
支持 回 压 ， 比 如 针对 请 求 所 要 求 的 数量 ， 控 制 读 取 多 少 行 。 
通过 JDBC 读 取 数据 库 也 是 阻塞 的 ， 并 且 是 基于 拉 取 模式 的 ， 可 以 通过 对 每 个 下 游 
请 求 调用 ResuLtSet .next() 来 进行 控制 。 
网 络 〈 流 式 ) IO 的 场景 下 ， 如 果 网 络 或 者 所 使 用 的 协议 能 够 支持 请 求 一 定 的 逻辑 数 
量 的 元 素 。 无论 是 网 络 帮助 还 是 使 用 的 协议 支持 都 请 求 一 定 的 逻辑 数量 。 
很 多 阻塞 式 和 基于 拉 取 模式 的 数据 源 ， 最 终 可 能 会 在 未 来 获得 非 阻塞 的 反应 式 APL 
驱动 。 


C.1.5 Single 


2x 中 的 single 反应 式 基础 类 型 进行 了 重新 设计 ， 能 够 发 布 一 个 onSuccess 或 onError 通 
知 。 它 的 架构 来 源 于 反应 式 流 的 设计 。 它 的 消费 者 类 型 (rx.Single.SingleSubscriber<T>) 
已 经 从 接收 rx.Subscription 资源 的 类 变更 为 io.reactivex.SingleObserver<T> 接口 ， 该 接 
只 有 3 种 方法 。 
interface SingleObserver<T> { 
void onSubscribe(Disposable d); 


void onSuccess(T value); 
void onError(Throwable error); 





































































































} 
它 遵 循 的 协议 为 : onSubscribe (onSuccess | onError)?。 


C.1.6 Completable 


Completable 类 型 基本 上 和 原来 相同 ，1x 版 本 的 设计 就 遵循 了 反应 式 流 的 风格 ， 因 此 没有 
用 户 级 别 的 变更 。 

名 称 的 变化 非常 类 似 ，rx.Completable.CompletableSubscriber 变 成 了 io.reactivex. 
CompletableObserver ， 后 者 现在 具有 onSubscribe(Disposable) 方法 。 
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interface CompletableObserver<T> { 
void onSubscribe(Disposable d); 
void onComplete(); 
void onError(Throwable error); 


} 
它 遵 循 的 协议 依然 为 : onSubscribe (onComplete| onError)?。 


C.1.7 Maybe 


RxJava 2.0.0-RC2 引入 了 一 个 新 的 反应 式 基础 类 型 Maybe。 从 概念 上 讲 ， 它 是 single 和 
Completable 的 组 合体 ， 能 捕获 的 发 布 模式 是 0 个 条 目 、1 个 条 目 或 来 自 反 应 式 源 的 一 个 错误 。 
Maybe 类 的 基础 接口 类 型 为 MaybeSource， 其 信号 接收 接口 为 Maybe0bserver<T>， 它 遵循 的 
协议 为 onSubscribe (onSuccess | onError | onComplete)?。 因 为 可 能 最 多 只 发 布 一 个 元 
素 ， 所 以 Maybe 类 型 没有 回 压 的 理念 ( 它 不 可 能 像 Flowable 或 Observable 那样 ， 因 为 未 知 
的 元 素 长 度 带 来 缓冲 区 的 膨胀 ) 。 


这 意味 着 调用 onSubscribe(Disposable) 之 后 ， 可 能 会 紧 跟着 调用 一 个 其 他 的 onXXX 方法 。 
与 Flowable 不 同 ， 如 果 仅 发 布 一 个 值 ， 这 里 只 会 调用 onSuccess， 而 不 会 调用 onCompLete。 


使 用 这 个 新 的 反应 式 基础 类 型 和 使 用 其 他 类 型 几乎 相同 ， 因 为 它 是 Flowabte 操作 符 的 一 个 
子 集 ， 这 些 操作 符 适 用 于 0 个 或 1 个 条 目 组 成 的 序列 。 

Maybe .just(1) 

.map(v -> V+1) 

.filter(v -> v == 1) 

.defaultIfEmpty(2) 

.test() 

.assertResult(2); 


C.1.8 基础 的 反应 式 接口 
与 Flowable 中 的 扩展 反应 式 流 的 Publisher<T> 风格 类 似 ， 甚 他 的 反应 式 基 础 类 也 扩展 了 
类 似 的 基础 接口 (在 io.reactivex 包 中 )。 


interface ObservableSource<T> { 
void subscribe(Observer<? super T> observer); 


























} 


interface SingleSource<T> { 
void subscribe(SingleObserver<? super T> observer); 


} 


interface CompletableSource { 
void subscribe(CompletableObserver observer); 


} 


interface MaybeSource<T> { 
void subscribe(MaybeObserver<? super T> observer); 


} 
因此 ， 很 多 需要 反应 式 基础 类 型 的 操作 符 可 以 接收 Publisher 和 XSource 了 。 
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Flowable<R> flatMap(Function<? super T，? extends Publisher<? extends R>> mapper); 


Observable<R> flatMap(Function<? super T，? extends ObservableSource<? extends R>> 
mapper ) ; 


通过 将 Publisher 作为 输入 ， 可 以 组 合 其 他 兼容 反应 式 流 的 库 ， 而 不 需要 再 将 它们 进行 包 
装 并 转换 为 FLowabLe 了 。 

但 是 ， 如 果 一 个 操作 符 必 须要 提供 反应 式 基 础 类 型 ， 那 么 用 户 会 接收 到 完整 的 反应 式 类 
(给 用 户 分 发 一 个 Xsource 其 实 没 有 什么 用 处 ， 因 为 没有 它 的 操作 符 )。 


FLowabLe<FLowabLe<Integer>> windows = source.window(5); 



































source.compose((Flowable<T> flowable) -> 
flowable 
.SubscribeOn(Schedulers.io()) 
.observeOn(AndroidSchedulers.mainThread())); 


C.1.9 _ Subject 和 Processor 


在 反应 式 流 规范 中 ， 类 似 Subject 的 行为 ( 即 同 时 是 事件 的 消费 者 和 提供 者 ) 已 经 通过 
org.reactivestreams.Processor 接口 实现 了 。 随 着 0bservable/Flowable 的 拆 分 ， 能 够 感知 
回 压 、 符 合 反 应 式 流 规范 的 实现 是 基于 FlowableProcessor<T> 类 的 〈 它 扩展 了 FLowablte 以 
提供 丰富 的 实例 操作 符 )。 关 于 Subject (以 及 它 的 扩展 FlowableProcessor) 还 有 一 个 重要 
的 变化 : 它们 不 再 支持 类 似 T -> R 的 转换 ( 即 输 入 TT 类型， 输出 R 类 型 )。1.x 中 从 未 使 用 
过 它 ， 而 原始 的 Subject<T，R> 来自 .NET，.NET 有 一 个 Subject<T> 重 载 ， 因 为 .NET 允 
许 相 同 的 类 名 和 不 同 数 量 的 类 型 参数 。 


在 2x 中 ，io.reactivex.subjects.AsyncSubject、io.reactivex.subjects.BehaviorSubject、 























io.reactivex.subjects.PublishSubject、 io.reactivex.subjects.ReplaySubject 和 
io.reactivex.subjects.UnicastSubject 不 支持 回 压 (因为 它们 是 0bservable 家 族 的 一 部 分 ) 。 


io.reactivex.processors.AsyncProcessor、io.reactivex.processors.BehaviorProcessor 、 
io.reactivex.processors.Publishprocessor、 io.reactivex.processors.ReplayProcessor 





和 io.reactivex.processors.UnicastProcessor 能 够 感知 回 压 。BehaviorProcessor 和 
PubLishProcessor 不 会 协调 下 游 订阅 者 请 求 (这 一 点 要 通过 Flowable.publish() 来 实现 )， 
如 果 下 游 的 处 理 节奏 跟 不 上 ， 会 以 MissingBackpressureException 的 形式 通知 它们 。 其 他 
的 XProcessor 类 型 在 回 压 方 面 能 够 遵循 下 游 订阅 者 的 请 求 量 ,， 但 是 当 订 阅 某 个 源 (可 选 
的 ) 时 ， 它 们 会 以 无 界 的 方式 进行 消费 (请求 Long.MAX_VALUE)。 

1. TestSubject 

1x 版 本 的 TestSubject 已 经 废弃 了 。 它 的 功能 可 以 通过 TestScheduLer、PubLishProcessor/ 
Publishsubject 和 observe0n(testScheduLer)/ 调度 器 参数 实现 。 











TestScheduler scheduler = new TestScheduler(); 
PublishSubject<Integer> ps = PublishSubject.create(); 


TestObserver<Integer> ts = ps.delay(1000, TimeUnit.MILLISECONDS, scheduler) 
.test(); 
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ts.assertEmpty(); 

ps.onNext(1); 

scheduler .advanceTimeBy(999, TimeUnit.MILLISECONDS); 
ts.assertEmpty(); 

scheduler .advanceTimeBy(1, TimeUnit.MILLISECONDS); 
ts.assertValue(1); 


2. SerializedSubject 





SeriaLizedSubject 不 再 是 一 个 公开 类 (public class) ， 必 须要 使 用 Subject.toSerialized() 





和 FlowableProcessor .toSerialized() 作为 替代 。 


C.1.10 其 他 的 类 


rx.observables.ConnectableObservable 拆 分 为 io.reactivex.observabLes.ConnectabLe0bservabLe<T> 


和 to.reactivex.fLowabLes.ConnectabLeFLowabLe<T>。 


GroupedObservable 
rx.observables.GroupedObservable 拆 分 为 io.reactivex.observa 


和 io.reactivex.fLowabLes.GroupedFLowabLe<T>。 


在 1x 中 ,你 可 以 通过 GroupedobservabtLe.from() 创建 一 个 只 有 





bles.GroupedObservable<T> 





E 1x 内 部 使 用 的 实例 。 在 





2x 中 ， 所 有 的 用 例 都 可 以 直接 扩展 Grouped0bservabte， 所 以 工厂 方法 没有 必要 存在 了 ， 


整个 类 现在 变 成 了 抽象 的 。 


我 们 可 以 直接 扩展 这 个 类 并 添加 自 定义 的 subscribeActual 行为 ， 实 现 类 似 1x 的 特性 。 





class MyGroup<K, V> extends Grouped0bservabLe<K，V> { 
final K key; 


final Subject<V> subject; 


public MyGroup(K key) { 
this.key = key; 
this.subject = PublishSubject.create(); 


} 


@Override 

public T getKey() { 
return key; 

} 


@Override 


protected void subscribeActuaL(Observer<? super T> observer) { 


subject. subscribe(observer); 
} 
} 


(这 一 方式 对 于 GroupedFlowable 也 是 有 效 的 。) 
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C.1.11 函数 式 接口 


因为 1x 和 2x 面 向 的 都 是 Java 6+， 所 以 无 法 使 用 Java 8 的 函数 式 接 口 ， 比 如 java.util. 
function.Function。 于 是 ，1.x 定义 了 自己 的 函数 式 接 口 ，2.x 延续 了 这 一 传统 。 


很 重要 的 一 个 变化 就 是 所 有 的 函数 式 接口 都 定义 了 throws Exception。 这 对 于 消费 者 和 
映射 器 是 非常 便利 的 ， 否 则 ， 如 果 抛 出 异常 ， 就 需要 try-catch 语句 来 转换 或 抑制 检查 
型 异常 。 

Flowable.just("file.txt") 


.map(name -> Files.readLines(name)) 
.Subscribe(lines -> System.out.println(lines.size()), Throwable::printStackTrace); 


如 果 文 件 不 存在 或 者 无 法 正确 读 取 ， 那 么 终端 用 户 会 直接 打印 出 IOException。 注 意 ， 在 
没有 try-catch 的 情况 下 ，Files.readLines(name) 也 被 调用 了 。 
1. Action 


鉴于 这 是 一 个 减少 组 件数 量 的 机 会 ，2.x 没有 定义 Action3-Action9 以 及 ActionN (RxJava 
本 身 没 有 用 到 它们 )。 


剩余 接口 的 名 称 按照 相应 的 Java 8 函数 式 类 型 进行 了 命名 。 无 参 的 Actiong 由 io.reactivex. 
functions.Action 替换 以 用 于 各 种 操作 符 ， 而 Schedule 方法 则 会 使 用 java.lang.Runnable。 
Action1 重 命 名 为 Consumer ，Action2 则 称 为 BiConsumer ，ActionN 替换 为 Consumer<0bject[]> 


类 型 声明 。 

2. Function 

我 们 遵循 Java 8 的 命名 约定 ， 定 义 了 io.reactivex.functions.Function 和 io.reactivex . 
functions.BiFunction， 同 时 相应 地 将 Func3-Func9 重 命 名 为 Function3-Function9。FuncN 
替换 为 Function<0bject[] ，R> 类 型 声明 。 

除 此 之 外 ， 需 要 断言 的 操作 符 现在 不 再 使 用 Function<0bject[]，R> 了 ， 而 是 有 了 一 个 单 
独 的 、 返 回 原始 类 型 的 Predicate<T> (因为 没有 自动 拆 箱 ， 能 够 实现 更 好 的 内 联 )。 














SR 























C.1.12 Subscriber 


反应 式 流 规范 有 自己 的 Subscriber 接口 。 这 个 接口 是 轻 量 级 的 ， 它 将 请 求 管 理 和 取消 放 到 
了 一 个 接口 中 ， 也 就 是 org.reactivestreams.Subscription， 而 不 是 分 别 使 用 rx.Producer 
和 rx.Subscription。 这 样 ， 相 对 于 1x 中 重量 级 的 rx.Subscriber，2.x 在 创建 流 的 消费 者 
时 可 以 使 用 更 少 的 内 部 状态 。 
Flowable.range(1, 10).subscribe(new Subscriber<Integer>() { 
@Override 


public void onSubscribe(Subscription s) { 
s.request(Long.MAX_VALUE ) ; 











@Override 
public void onNext(Integer t) { 
System.out.println(t); 
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} 


@Override 
public void onError(Throwable t) { 
t.printStackTrace(); 


} 


@Override 
public void onComplete() { 
System.out.println("Done"); 


} 
}); 
因为 名 称 的 冲突 ， 单 纯 地 将 包 名 从 rx 替换 为 org.reactivestreams 是 不 够 的 。 除 此 之 外 ， 








org.reactivestreams.Subscriber 没有 添加 资源 、 取 消 资 源 或 者 从 外 部 进行 请 求 的 语义 。 


为 了 弥合 这 一 差异 ， 我 们 为 Flowable (和 0bservable) 定义 了 抽象 类 DefaultSubscriber、 
ResourceSubscriber 和 DisposableSubscriber (以 及 XObserver 变种 形式 )， 提 供 了 像 
rx.Subscriber 一 样 的 资源 跟踪 (以 Disposable 的 形式 ) 功能 ， 并 且 能 够 在 外 部 通过 





dispose() 进行 取消 。 


ResourceSubscriber<Integer> subscriber = new ResourceSubscriber<Integer>() { 


@Override 

public void onStart() { 
request(Long.MAX_VALUE ) ; 

} 


@Override 
public void onNext(Integer t) { 
System.out.println(t); 


} 


@Override 
public void onError(Throwable t) { 
t.printStackTrace(); 


} 


@Override 
public void onComplete() { 
System.out.println("Done"); 
} 
}; 


Flowable.range(1, 10).delay(1, TimeUnit.SECONDS).subscribe(subscriber); 


subscriber .dispose(); 


注意 ， 同 样 
的 字母 d。 





Ba 




















Subscription 添加 到 一 个 CompositeSubscription 中 ， 如 下 所 示 。 


在 1.x 中 ，0bservabtLe.subscribe(Subscriber) 返回 的 是 Subscription， 所 以 用 户 经 


为 反应 式 流 的 兼容 性 ，onCompleted 重 命 名 为 onComptete， 去 掉 了 最 后 结尾 





RxJava 1.0 至 RxJava 2.0 的 迁移 指南 


| 279 


CompositeSubscription composite = new CompositeSubscription(); 


composite.add(Observable.range(1, 5).subscribe(new TestSubscriber<Integer>())); 


根据 反应 式 流 规 范 ，Publisher .subscribe 返回 的 是 void， 所 以 这 种 模式 本 身 不 再 适用 于 2.0。 
为 了 修正 这 一 点 ， 我 们 在 每 个 反应 式 基 础 类 中 都 添加 了 E subscribeWith(E subscriber) 方 
法 ， 它 会 原样 返回 传 入 的 subscriber/observer。 在 前 面 两 个 样 例 中 ，2.x 的 代码 可 以 如 下 
所 示 ， 因 为 ResourceSubscriber 直接 实现 了 Disposable。 




















CompositeDisposable composite2 = new CompositeDisposable(); 
composite2.add(Flowable.range(1, 5).subscribeWith(subscriber)); 


从 onSubscribe/onStart 调 用 请 求 

由 于 请 求 管 理 的 运行 机 制 ， 在 Subscriber.onSubscribe 或 ResourceSubscriber.onStart 中 
调用 request(n) 可 能 会 立即 触发 对 onNext 的 调用 ， 对 onNext 的 调用 有 可 能 会 在 request( ) 
返回 至 onSubscribe/onStart 方法 前 执行 。 








Flowable.range(1, 3).subscribe(new Subscriber<Integer>() { 


@Override 

public void onSubscribe(Subscription s) { 
System.out.println("OnSubscribe start"); 
s.request(Long.MAX_VALUE ) ; 
System.out.println("OnSubscribe end"); 


} 


@Override 
public void onNext(Integer v) { 
System.out.println(v); 


} 


@Override 
public void onError(Throwable e) { 
e.printStackTrace(); 


} 


@Override 
public void onComplete() { 
System.out.println("Done"); 
} 
]); 


上 述 代码 会 打印 出 以 下 结果 。 


OnSubscribe start 
1 

2 

3 

Done 

OnSubscribe end 


这 里 的 问题 在 于 ， 如 果 有 人 希望 在 调用 request 之 后 在 onSubscribe/onStart 中 执行 一 些 初 
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始 化 逻辑 ， 那 么 onNext 有 可 能 会 看 到 初始 化 的 效果 ， 也 有 可 能 看 不 到 。 为 了 避免 这 种 情 
况 ， 需 要 确保 在 onSubscribe/onStart 中 ， 等 到 所 有 的 初始 化 都 完成 后 再 调用 request。 
这 种 行为 与 1x 不 同 ， 在 1x 中 ，request 会 经 过 一 个 延迟 的 逻辑 来 累积 请 求 ， 直 到 上 游 的 
Producer 在 某 个 时 刻 出 现 (这 种 行为 给 所 有 1x 中 的 操作 符 和 消费 者 带 来 了 一 定 的 开销 )。 在 
2x 中 ， 始 终 会 首先 得 到 一 个 Subscription， 在 90% 的 情况 下 没有 必要 对 请 求 进行 延迟 。 

















C.1.13 Subscription 

在 RxJava 1x 中 ，rx.Subscription 接口 负责 流 和 资源 的 生命 周期 管理 ， 即 取消 对 序列 的 订 
阅 并 释放 通用 的 资源 ， 如 调度 的 任务 。 反 应 式 流 规范 使 用 这 个 名 称 来 指定 源 和 消费 者 的 交 
互 点 : org.reactivestreams.Subscription。 它 允许 请 求 上 游 流 中 的 一 个 正 数 ， 并 允许 取消 
对 序列 的 订阅 。 

为 了 避免 名 称 的 冲突 ，1.x 的 rx.Subscription 重 命名 为 io.reactivex.Disposable (有 点 类 
似 于 .NET 自己 的 IDisposable)。 

为 反应 式 流 规范 的 基础 接口 org.reactivestreams.Publisher 将 subscribe() 方 法 定 
义 为 void， 所 以 Flowable.subscribe(Subscriber) 不 会 再 返回 任何 Subscription (或 
Disposable)。 其 他 的 反应 式 基 础 类 型 也 遵循 这 个 签名 ,分 别 对 应 各 自 的 订阅 者 类 型 。 


原始 的 Subscription 类 型 分 别 进行 了 重 命名 和 更 新 。 


CompositeSubscription 变 为 CompositeDisposable。 














SerialSubscription 和 MultipleAssignmentSubscription 合并 为 SerialDisposable。set() 
方法 取消 了 旧 值 ， 但 是 replace() 方法 不 会 这 样 做 。 
RefCountSubscription 被 移 除 。 


C.1.14 回 压 


反应 式 流 规范 要 求 操作 符 支 持 回 压 ， 尤 其 是 消费 者 没有 请 求 数据 的 时 候 ， 要 确保 它们 不 会 溢 
出 。 新 的 基础 反应 式 类 型 Flowable 的 操作 符 能 够 正确 地 考虑 下 游 请 求 的 数量 ,但 是 这 并 不 
意味 着 忆 ssingBackpressureException 不 会 再 出 现 。 这 个 异常 依然 存在 ， 但 是 这 次 ， 不 能 发 
布 更 多 onNext 信号 的 操作 符 将 发 布 这 个 异常 〈 以 识别 哪个 操作 符 没 有 恰当 地 处 理 回 压 )。 


作为 替代 方案 ，2.x 的 0bservable 完全 不 支持 回 压 ， 可 以 作为 切换 的 备用 选项 。 


C.1.15” 订 循 反应 式 流 协 议 

更 新 至 2.0.7 版 本 

在 2.0.7 版 本 中 ， 基 于 Flowable 的 源 和 操作 符 已 经 完全 符合 1.0.0 版 本 的 反应 式 流 规范 。 
在 2.0.7 版 本 之 前 ， 为 了 实现 同等 级 别 的 兼容 性 ， 必 须要 使 用 strict() 操作 符 。 在 2.0.7 版 本 
中 ，strict() 操作 符 会 返回 this， 前 者 已 经 被 弃 用 ， 在 2.1.0 版 本 中 将 完全 移 除 该 操作 符 。 
作为 RxJava 2.0 版 本 的 主要 目标 之 一 ， 设 计 主 要 聚焦 于 性 能 方面 。 为 了 实现 该 目标 ， 
RxJava 2.0.7 添 加 了 一 个 自 定义 的 io.reactivex.FlowableSubscriber 接口 (扩展 了 
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org.reactivestreams.Subscriber)， 但 是 并 没有 为 其 添加 新 方法 。 这 个 新 的 接口 限制 在 
RxJava 2.0 中 使 用 ， 它 代表 了 FLowablte 的 某 个 消费 者 在 反应 式 规 范 1.0.0 版 本 的 8 1.3、 
8$823、82.12 和 83.9 方面 要 放松 限制 。 


。 8S 1.3 规则 放宽 : 如 果 FlowableSubscriber 在 onSubscribe 中 调用 request()，onSubscribe 
可 能 会 与 onNext 并 发 运行 ，FLowabLeSubscriber 需要 确保 onSubscribe 中 的 剩余 指令 与 
onNext 之 间 的 线程 安全 性 。 

。 8S$2.3 规则 放宽 : 在 FLowabLeSubscriber .onCompLete() 或 FLowabLeSubscriber .onError() 
中 调用 Subscription.cancel 和 Subscription.request 视 为 不 进行 任何 操作 。 

。 S22.12 规则 放宽 : 如 果 相 同 的 FlowableSubscriber 实例 被 订阅 到 了 多 个 源 上 ， 它 必须 要 
确保 其 onXXX 方法 保持 线程 安全 。 

。 8$3.9 规 则 放宽 : 发 出 非 正 数 的 request0 不 会 停止 当前 的 流 ， 而 是 会 通过 RxJavaPlugins. 
onError 发 布 错误 信号 。 

从 用 户 的 角度 ， 如 果 使 用 subscribe 而 不 是 Flowable. subscribe(Subscriber<? super T>)， 

则 无 须 对 这 个 变更 采取 任何 措施 ， 也 不 会 有 额外 的 惩罚 。 

如 果 用 户 组 合 使 用 了 Flowable.subscribe(Subscriber<? super T>) 和 内 置 的 RxJava 实 

现 ， 比 如 DisposableSubscriber、TestSubscriber 和 ResourceSubscriber， 而 代码 没有 针对 

2.0.7 重新 编译 ， 那 么 这 会 带 来 一 个 很 小 的 运行 时 开销 (一 个 instanceof 检查 )。 

如 果 之 前 已 经 有 了 自 定义 的 Subscriber 类 实现 ， 那 么 使 用 它 订 阅 Flowable 会 添加 一 个 内 部 

包装 器 ， 以 确保 观察 的 Flowable 能 够 100% 遵循 规范 ， 但 是 会 给 每 个 条 目 带 来 一 定 的 开销 。 

为 了 移 除 这 些 额 外 的 开销 ，Flowable.subscribe(FlowableSubscriber<? super T>) 添加 

了 一 个 新 方法 ， 它 能 够 暴露 2.0.7 版 本 之 前 的 原始 行为 。 建 议 新 的 自 定义 消费 者 实现 

FlowableSubscriber ， 而 不 仅仅 是 实现 Subscriber。 


C.1.16 ”运行 时 挂钩 
2.x 重新 设计 了 RxJavaPlugins 类 ， 从 而 支持 在 运行 时 修改 挂钩。 测试 想 要 履 盖 调度 器 和 基 
础 反应 式 类 型 的 生命 周期 ， 我 们 可 以 通过 回调 函数 按 不 同情 况 实现 。 


基于 RxJava0bservableHook 的 相关 类 已 经 被 移 除 ，RxJavaHooks 的 功能 合并 到 了 RxJava- 
Plugins 中 。 


C.1.17 错误 处 理 


2x 版 本 有 一 个 很 重要 的 设计 需求 : 不 吞噬 任何 Throwable 错误 。 这 意味 着 某 些 无 法 发 布 的 
错误 需要 得 到 特殊 的 处 理 ， 因 为 下 游 的 生命 周期 已 经 到 了 终结 状态 ,或 者 下 游 取 消 了 对 一 
个 即将 发 布 错误 的 序列 的 订阅 。 

这 样 的 错误 会 被 路 由 至 RxJavaPlugins .onError 处 理 器 。 这 个 处 理 器 可 以 通过 RxJavaPlugiins. 
setErrorHandler(Consumer<Throwable>) 进行 重 写 。 如 果 没 有 指定 处 理 器 ，RxJava 会 默 
认 在 控制 台 打 印 出 Throwable 的 堆栈 ， 并 调用 当前 线程 的 未 捕获 异常 处 理 代 码 (uncaught 


exception handler ) 。 
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在 桌面 Java 上 ， 后 面 提 到 的 处 理 代码 不 会 在 ExecutorService 支撑 的 Scheduler 做 任何 事 
情 ， 应 用 程序 会 继续 运行 。 但 是 ，Android 会 更 加 严格 ， 如 果 遇 到 这 样 的 未 捕获 异常 ， 将 
会 终止 应 用 程序 。 

如 果 这 种 行为 是 必要 的 ， 那 另 当 别论 。 但 是 在 有 些 场景 下 ， 如 果 我 们 想 要 避免 对 未 捕获 异 
常 处 理 代码 的 调用 ， 那 么 使 用 RxJava 2.0 (直接 或 间接 ) 的 最 终 应 用 程序 需要 定义 一 个 不 
执行 任何 操作 (no-op) 的 处 理 代码 。 

// 如 果 支 持 Java 8 Lambda 表 达 式 的 话 


RxJavaPlugins.setErrorHandler(e -> { }); 






























































// 如 果 没 有 Retrolambda 或 Jack 的 话 


RxJavaPlugins.setErrorHandler(Functions.<Throwable>emptyConsumer()); 

不 建议 中 间 库 在 自己 的 测试 环境 之 外 更 改 错误 处 理 代码 。 

令 人 遗憾 的 是 ，RxJava 无 法 判断 哪些 异常 超出 了 生命 周期 ， 未 投递 的 异常 是 否 应 该 终止 应 

用 程序 。 识 别 这 些 异 常 的 来 源 非 常 麻 烦 ， 如 果 它 们 来 源 于 链 中 的 某 个 较为 底层 的 源 并 路 由 

至 RxJavaPlugins.onError， 这 会 尤为 困难 。 

因此 ，2.0.6 版 本 引入 了 特定 的 异常 包装 器 ， 帮 助 识 别 和 跟踪 当 错 误 出 现时 的 情况 。 

。 OnErrorNotImplementedException: 重新 引入 该 异常 以 探测 用 户 忘 记 为 subscribe() 添加 
错误 处 理 的 场景 。 

。 ProtocolViolationException: 表明 操作 符 中 的 缺陷 。 

。 UndeLiverabLeException: 包装 由 于 Subscriber/0bserver 的 生命 周期 限制 无 法 进行 投 
递 的 原始 异常 。RxJavaPlugins.onError 会 自动 应 用 该 异常 ， 并 且 带 有 完整 的 堆栈 轨迹 ， 
这 样 有 助 于 发 现 哪 个 操作 符 重 新 路 由 了 原始 的 错误 。 

如 果 未 投递 的 异常 是 NullPointerException、IllegalStateException (UndeliverableException 和 

ProtocolViolationException 扩展 了 该 异常 )、ILLegaLArgumentException 、 CompositeException、 

MissingBackpressureException 或 OnErrorNotImplementedException 的 实例 或 后 代 ， 将 不 会 

包装 为 UndeliverableException。 


此 外 ， 有 些 第 三 方 库 被 canceUdispose 打 断 的 时 候 ， 大 多 数 情况 下 抛 出 的 异常 会 无 法 投 
递 。2.0.6 版 本 有 一 些 内 部 变化 ， 它 会 在 处 理 任务 或 worker (这 会 导致 目标 线程 的 中 断 ) 之 
前 处 理 Subscription/Disposable。 


// 在 某 些 库 中 
try { 
doSomethingBlockingly() 
} catch (InterruptedException ex) { 
// 检 查 是 否 因 为 取消 而 中 断 
// 如 果 是 这 样 的 话 ， 则 没有 必要 发 布 InterruptedException 信 号 
if (!disposable.isDisposed()) { 
observer .onError(ex); 






























































} 
} 


如 果 库 /代码 已 经 这 样 做 了 ， 未 投递 的 InterruptedException 应 该 到 此 为 止 。 如 果 以 前 没 
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有 采取 这 种 模式 ， 我 们 推荐 更 新 相关 的 代码 / 库 。 
如 果 决 定 添加 非 空 的 全 局 错误 消费 者 ， 它 会 管理 较为 典型 的 未 投递 异常 ， 处 理 过 程 会 判断 
这 是 一 个 bug 还 是 一 种 可 忽略 的 应 用 程序 / 网 络 状 态 ， 如 下 所 示 。 


RxJavaPlugins.setErrorHandler(e -> { 
if (e instanceof UndeliverableException) { 
e = e.getCause(); 
































} 

if ((e instanceof IOException) || (e instanceof SocketException)) { 
// 不 相关 的 网 络 问题 或 API 导 致 了 取消 
return; 


if (e instanceof InterruptedException) { 
// 一 些 阻塞 代码 被 dispose 调 用 中 断 


return; 


if ((e instanceof NullPointerException) || (e instanceof 
IllegalArgumentException)) { 
// 似 乎 是 应 用 的 bug 
Thread.currentThread().getUncaughtExceptionHandler() 
.handleException(Thread.currentThread(), e); 
return; 
} 
if (e instanceof IllegalStateException) { 
//RxJava 或 自 定义 操作 符 中 的 bug 
Thread.currentThread().getUncaughtExceptionHandler() 
.handleException(Thread.currentThread(), e); 
return; 





} 


Log.warning("Undeliverable exception received, not sure what to do", e); 


}); 


C.1.18 Scheduler 


2x 版 本 的 API 依 然 支 持 大 多 数 的 默认 调度 器 类 型 : computation、io、newThread 和 
trampoLine， 它 们 可 以 通过 io.reactivex.schedulers.Schedulers 工具 类 来 使 用 。 

2x 中 已 经 没有 immediate 了 ， 它 经 常 被 误 用 ， 并 且 没 有 正确 地 实现 Scheduler 规范 。 它 
为 延迟 操作 包含 了 阻塞 式 的 休眠 ， 并 且 不 支持 递归 调度 。 现 在 ， 应 该 使 用 schedulers. 
trampoline() 来 奉 代 它 。 

Schedulers.test() 也 被 移 除了 ， 从 而 避免 出 现 与 其 他 默认 调度 器 概念 上 的 混淆 。 其 他 的 类 
型 都 会 返回 一 个 “全 局 ”调度 器 ， 而 test() 始终 都 会 返回 一 个 新 的 Testscheduler 实例 。 
我 们 鼓励 开发 人 员 在 代码 中 直接 使 用 new TestSchedutLer()。 

io.reactivex.Scheduler 抽象 基础 类 现在 能 够 直接 调度 任务 ， 不 再 需要 创建 和 销毁 Worker 
(经 常 被 遗忘 ) 了 。 


public abstract class Scheduler { 























public Disposable scheduleDirect(Runnable task) { ...} 
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public Disposable scheduleDirect(Runnable task, long delay, TimeUnit unit) { 


.} 
public Disposable scheduleDirectPperiodically(Runnable task, long initialDelay, 
Long period, TimeUnit unit) { ... } 
public Long now(TimeUnit unit) { ... } 








//…… 甚 余 都 是 一 样 的 : 生命 周期 方法 、 创 建 worker 
} 
主要 目的 是 避免 一 次 性 的 任务 跟踪 Worker 带 来 的 开销 。 方 法 有 一 个 默认 实现 ， 它 会 重用 
createWorker ， 如 果 必 要 ， 可 以 用 更 高 效 的 实现 来 重 写 它 。 
方法 会 返回 调度 器 本 身 对 当前 时 间 的 理解 ，now() 改 为 接收 一 个 Timeunit， 用 来 指明 度量 
单位 。 


C.1.19 进入 反应 式 的 世界 


RxJava 1x 的 一 个 设计 缺陷 是 对 外 暴露 了 rx.0bservable.create() 方 法， 尽管 它 非常 强大 ， 
但 它 并 不 是 进入 反应 式 世 界 应 该 使 用 的 典型 操作 符 。 令 人 遗憾 的 是 ， 太 多 的 人 依赖 这 个 方 
法 ， 我 们 不 能 移 除 它 或 者 对 其 重新 命名 。 
2 版 本 是 一 个 全 新 的 开始 ， 我 们 不 会 再 犯 这 样 的 错误 。 每 个 反应 式 基础 类 型 Flowable 、 
Observable、Single、Maybe 和 Completable 都 有 一 个 安全 的 create 操作 符 ， 在 回 压 (针对 
Flowable) 和 取消 (针对 所 有 类 型 ) 方面 ， 它 们 都 能 完成 正确 的 操作 。 
Flowable.create((FlowableEmitter<Integer> emitter) -> { 
emitter .onNext(1); 
emitter .onNext(2); 


emitter .onComplete(); 
}, BackpressureStrategy .BUFFER); 


实际 上 ，1x 的 fromEmitter (以 前 被 称 为 fromAsync) 已 经 更 名 为 Flowable.create。 其 他 
反应 式 基 础 类 型 有 类 似 的 create 方法 (缺少 回 压 策略 ) 。 


C.1.20 脱离 反应 式 的 世界 


除了 使 用 对 应 的 消费 者 (Subscriber、0bserver、SingLe0bserver、Maybe0bserver 和 
CompletableObserver) 和 基于 国 数 式 接口 (比如 subscribe(Consumer<T>，Consumer <ThrowabLe>， 
Action) 的 消费 者 订阅 基础 类 型 ，1x 中 独立 的 BlockingObservable (以 及 相似 的 类 ) 已 经 
集成 到 主要 的 反应 式 类 型 。 现 在 ,我 们 可 以 通过 blockingX 操作 直接 阻塞 以 获取 结果 。 
List<Integer> list = Flowable.range(1, 100).toList().blockingGet(); 
//toList() 


返回 Single 
Integer i = Flowable.range(100, 100).blockingLast(); 


(原因 有 两 个 : 使 用 该 库 作为 同步 Java 8 Streams 类 处 理 代码 的 性 能 和 易 用 性 。) 
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rx.Subscriber 和 org.reactivestreams.Subscriber 的 另 一 个 明显 差异 是 : 在 2x 中 ， 
Subscriber 和 0bserver 只 会 抛 出 致命 的 异常 (参见 Exceptions.throwIfFatal())， 而 不 





抛 出 其 他 异常 (反应 式 流 规范 能 够 在 onSubscribe、onNext 或 onError 接收 到 null 时 抛 出 








NullPointerException， 但 是 RxJava 根本 不 允许 null 出 现 )。 这 意味 着 如 下 代码 是 韭 法 的 。 


Subscriber<Integer> subscriber = new Subscriber<Integer>() { 


@Override 


public void onSubscribe(Subscription s) { 


s.request(Long.MAX_VALUE); 
} 


public void onNext(Integer t) { 
if (t == 1) { 


throw new IllegalArgumentException(); 


} 
} 


public void onError(Throwable e) { 


if (e instanceof IllegalArgumentException) { 
throw new UnsupportedOperationException(); 


} 
} 


public void onComplete() { 


throw new NoSuchElementException(); 


} 
}; 


Flowable.just(1).subscribe(subscriber); 


这 同样 适用 于 Observer、SingleObserver、MaybeObserver 和 CompletableObserver。 





鉴于 很 多 面向 1.x 的 代码 没有 按照 该 要 求 来 编写 ， 
处 理 这 些 不 符合 要 求 的 消费 者 。 








大 








此 我 们 引入 了 safeSsubscribe 方法 ,来 


另 一 种 赫 代 方案 是 使 用 subscribe(Consumer<T>，Consumer<Throwable>，Action) (和 类 似 
的 方法 ) ， 以 提供 可 以 抛 出 异常 的 回调 /lambda 表达 式 。 

















Flowable.just(1) 
.SUbscribe( 
subscriber: :onNext， 
subscriber::onError, 
subscriber::onComplete, 
subscriber::onSubscribe 


); 


C.1.21 测试 





在 测试 方面 ， RxJava 2x 的 运行 方式 与 1x 相同 。Flowable 可 以 使 用 io.reactivex. 
subscribers.TestSubscriber 进行 测试 ， 而 不 支持 回 压 的 Observable、Single、Maybe 和 
Completable 可 以 使 用 io.reactivex.observers.TestObserver。 
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1. test() 操 作 符 
为 了 支撑 我 们 的 内 部 测试 ， 现 在 所 有 的 反应 式 基础 类 型 都 有 test() 方法 (这 带 来 了 巨大 的 
便利 )， 会 返回 TestSubscriber 或 TestObserver。 





TestSubscriber<Integer> ts = Flowable.range(1, 5).test(); 
TestObserver<Integer> to = Observable.range(1, 5).test(); 
TestObserver<Integer> tso = Single.just(1).test(); 
TestObserver<Integer> tmo = Maybe.just(1).test(); 


TestObserver<Integer> tco = Completable.complete().test(); 


第 二 个 便利 之 处 在 于 大 多 数 的 TestSubscriber/Test0bserver 方法 都 会 返回 实例 本 身 ， 可 以 
将 各 种 assertX 方法 链接 起 来 。 第 三 个 便利 之 处 是 我 们 可 以 流畅 地 测试 源 ， 不 必 在 代码 中 
创建 或 引入 TestSubscriber/TestObserver 实例 。 








Flowable.range(1, 5) 
.test() 
.assertResult(1, 2, 3, 4, 5) 


3 


口 值得 注意 的 新 断言 方法 

















assertResult(T... items): 断言 如 果 进 行 订 阅 ， 则 按照 给 定 的 顺序 依次 接收 给 定 的 
条 目 ， 随 后 接收 到 onComplete 通知 ， 没 有 错误 出 现 。 

assertFailure(Class<? extends Throwable> clazz,，T... items): 断言 如 果 进 行 订 
阅 ， 则 按照 给 定 的 顺序 依次 接收 给 定 的 条 目 ， 随 后 出 现 一 个 Throwable 错误 ， 使 用 
clazz.isInstance() 判断 返回 true。 

assertFailureAndMessage(Class<? extends Throwable> clazz, String message, T... 
items) : 与 assertFailure 相同 , 除 此 之 外 , 还 要 校 验 getMessage() 包含 特定 的 信息 。 
awaitDone(long time，TimeUnit unit): 等 待 终端 事件 (阻塞 式 ) ， 如 果 出 现 超时 ， 
取消 对 序列 的 订阅 。 

assertOf(Consumer<TestSubscriber<T>> consumer): 将 一 些 断 言 组 合 到 一 个 流畅 的 
链 中 (在 内 部 用 于 融合 测试 ， 因 为 现在 操作 符 融 合 不 是 公共 API 的 一 部 分 ) 。 




















这 里 将 Flowable 替换 为 Observable 的 一 个 益处 是 : 由 于 从 TestSubscriber 到 TestObserver 
的 隐 式 类 型 转换 ， 测 试 代码 部 分 完全 不 需要 任何 变化 。 
2. 预先 取消 和 请 求 


TestObserver 的 test() 方法 有 一 个 test(boolean cancel) 的 重 载 形式 ， 它 会 在 真正 订阅 之 
前 就 取消 TestSubscriber/TestObserver。 





PublishSubject<Integer> pp = PublishSubject.create(); 


// 还 没有 人 订阅 


assertFalse(pp.hasSubscribers()); 


pp.test(true); 
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// 没 有 人 能 够 保持 订阅 


assertFalse(pp.hasSubscribers()); 


TestSubscriber 具 有 test(Long initialRequest) 和 test(Long initialReques 





t, boolean 


cancel) 的 重 载 形 式 ， 它 能 够 指定 初始 的 请 求 数量 以 及 TestSubscriber 是 否 应 该 立即 取消 。 








如 果 指 定 了 initialRequest， 还 可 以 使 用 TestSubscriber 提供 的 requestMore(1 
能 够 以 连贯 的 方式 保持 请 求 。 


Flowable.range(1, 5) 

.test(0) 

.assertValues() 
.requestMore(1) 
.assertValues(1) 
.requestMore(2) 
.assertValues(1, 2, 3) 
.requestMore(2) 
.assertResult(1, 2, 3, 4, 5); 


而 作为 替代 方案 ， 必 须要 捕获 TestSubscriber 实例 ， 以 访问 其 request() 方法 。 


Publishprocessor<Integer> pp = PubLishProcessor .create(); 
TestSubscriber<Integer> ts = pp.test(0L); 
ts.request(1); 


pp.onNext(1); 
pp.onNext(2); 


ts.assertFailure(MissingBackpressureException.class, 1); 


3. 测试 异步 源 
对 于 异步 源 ， 我 们 现在 可 以 连贯 地 阻塞 等 待 终端 事件 。 


Flowable.just(1) 
.SubscribeOn(Schedulers.single()) 
.test() 

.awaitDone(5, TimeUnit.SECONDS) 
.assertResult(1); 








4. Mockito & TestSubscriber 


ong)， 从 而 


如 果 在 1.x 版 本 中 使 用 Mockito 和 仿造 的 0bserver， 那 么 现在 必须 要 仿造 Subscriber . 


onSubscribe 方法 ， 以 发 起 初始 请 求 ， 否 则 ， 序 列 将 会 挂 起 ， 或 因 hot 类 型 的 源 蝇 





@SuppressWarnings("unchecked") 
public static <T> Subscriber<T> mockSubscriber() { 
Subscriber<T> w = mock(Subscriber.class); 


Mockito.doAnswer (new Answer<Object>() { 
@Override 
public Object answer(InvocationOnMock a) throws Throwable { 
Subscription s = a.getArgumentAt(0, Subscription.class); 
s.request(Long.MAX_VALUE); 


H 现 失败 。 
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return null; 
}).when(w).onSubscribe((Subscription)any()); 


return w; 


C.1.22 操作 符 的 差异 


在 2x 中 ， 大 多 数 操作 符 都 保留 了 下 来 ， 并 且 行 为 与 1x 中 相同 。 下 面 的 子 章节 列 出 了 每 个 
反应 式 基 础 类 型 以 及 1x 和 2.x 之 间 的 差异 。 


很 多 操作 符 都 增加 了 重 载 版 本 ， 可 以 指定 内 部 缓冲 的 大 小 或 者 在 上 游 流 〈 或 内 部 源 ) 上 预 
先 抓 取 的 数量 。 


et tn ks 重 命名 ， 比 如 fromArray、fromIterable 等 。 
原因 是 库 针 对 Java 8 进行 编译 时 ，javac 通常 无 法 消除 函数 式 接口 类 型 之 前 的 歧义 。 


在 1x 版 本 中 使 用 @Beta 或 @Experimental 标注 的 操作 符 现在 提升 到 了 标准 水 平 。 
从 1.x 的 0bservable 到 2.x 的 Flowable 

口 工厂 方法 〈 见 表 C-1) 

表 C-1: 工厂 方法 







































































WX 2 

amb 添加 amb(0bservableSource...) 重 载 形 式 ， 废 弃 2~9 个 参数 的 版 本 

RxRingBuffer .SIZE bufferSize() 

combineLatest 添加 可 变 参数 (varargs) 的 重 载 形式 ， 添加 带 有 buffersize 参数 的 重 载 形式 ， 
废弃 combineLatest(List) 

concat 添加 prefetch 参数 的 重 载 版 本 ， 废 弃 5~9 个 源 的 重 载 版 本 ， 使 用 concatArray 
作为 替代 方案 

N/A 添加 concatArray 和 concatArrayDelayError 

N/A 添加 concatArray 和 concatArrayDelayError 

concatDelayError 添加 重 载 形式 ， 能 够 延迟 到 当前 源 结束 或 所 有 源 结束 





ConcatEagerDeLayError 添加 重 载 形 式 ， 能 够 延迟 到 当前 源 结束 或 所 有 源 结束 
create(SyncOnSubscribe) ”替换 为 generate 及 重 载 形 式 (不 同 的 接口 ， 可 以 一 次 性 实现 它们 ) 
create(AsnycOnSubscribe) 不 复 存 在 了 









































create(OnSubscribe) 通过 安全 的 create(FLowabLe0nSubscribe， BackpressureStrategy) 重新 进行 了 
定义 ， 通 过 unsafeCreate() 支持 原 有 功能 

from 为 消除 歧义 ， 拆 分 到 了 fromArray、fromIterable 和 fromFuture 中 

N/A 添加 fromPubLisher 

fromAsync 重 命 名 为 create() 

N/A 添加 intervalRange() 

Limit 废弃 ， 使 用 take 

merge 添加 带 有 prefetch 的 重 载 形式 
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WX 2.X 

mergeDeLayError 添加 带 有 prefetch 的 重 载 形式 

sequenceEqual 添加 带 有 buffersize 的 重 载 形式 

switchOnNext 添加 带 有 prefetch 的 重 载 形 式 

switchOnNextDelayError 添加 带 有 prefetch 的 重 载 形 式 

timer 废弃 过 时 的 重 载 版 本 

zip 添加 带 有 buffersize 和 delayErrors 功能 的 重 载 版 本 ， 为 了 消除 歧义 改 为 





zipArray 和 zipIterable 


口 实例 方法 〈 见 表 C-2) 


表 C-2: 实例 方法 
























































1.X 2.X 

all RC3 返回 Single<Boolean> 

any RC3 返回 Single<Boolean> 

asObservable 重 命 名 为 hide()， 会 隐藏 所 有 的 标识 

buffer 添加 使 用 自 定义 CoLLection 供应 者 的 重 载 版 本 
cache(int) 废弃 

COLLect RC3 返回 SingLe<U> 


collect(U, Action2<U, T>) 


concatMap 


concatMapDelayError 


concatMapEager 


concatMapEagerDelayError 


count 

countLong 
distinct 
doOnCompleted 
doOnUnsubscribe 


N/A 


elementAt(int) 


elementAt(Func1, int) 


elementAtOrDefault(int, T) 


elementAtOrDefault(Funci1, 


int, T) 








为 了 消除 歧义 改 为 collectInto， 





并 且 RC3 返 区 








Single<U> 





添加 带 有 prefetch 的 重 载 形式 


添加 带 有 prefetch 的 对 


有 源 结束 





添加 带 有 prefetch 的 重 载 形式 
添加 了 带 有 prefetch 的 重 载 形式 ， 





结束 
RC3 返 下 
废弃 ， 
添加 使 用 















































重 命名 为 do0nCompLete， 
重 命名 为 Flowable.doOnCancel， 
添加 了 doonLifecytLce 来 处 理 霓 探 onSubscribe、 








E 载 形式 ， 能 够 延迟 到 当前 源 结束 或 延迟 到 所 








能 够 延迟 到 当前 源 结束 或 所 有 源 








Single<Long> 
使 用 count 替代 
定义 Collection 供应 者 的 重 载 版 本 


注意 少 了 一 个 d 
其 他 类 型 重 命 名 为 do0nDispose 























request 和 cancel 














如 果 源 的 长 度 小 于 索引 ，RC3 将 不 再 标志 NoSuchElementException 
废弃 ,使 用 filter(predicate).elementAt(int) 


























更 
重 命名 为 eLementAt(int，T)，RC3 返 
例 用 filter(predicate).elementAt(int, T) 





回 SingLe<T> 


























first() RC3 重 命名 为 firstElement 并 返回 Maybe<T> 
first(Func1) 废弃 ， 使 用 filter(predicate).first() 
firstOrDefauLt(T) 重 命名 为 first(T)，RC3 返回 Single<T> 
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1.X 


2.X 





firstOrDefauLt(Func1，T) 
flatMap 
N/A 


groupBy 


ignoreElements 

isEmpty 

last() 

last(Func1) 
LastOrDefautLt(T) 
LastOrDefauLt(Func1，T) 
nest 

publish(Func1) 
reduce(Func2) 


N/A 


N/A 
repeatWhen(Func1, Scheduler) 


retry 
N/A 
retryWhen(Func1, Scheduler) 


sample 


N/A 


single() 

single(Func1) 
singleOrDefault(T) 
singleOrDefault(Func1, T) 
skipLast 

startwith 


N/A 


subscribe 


废弃 ,使 用 filter(predicate).first(T) 


添加 带 有 prefetch 的 重 载 形式 
添加 forEachwhile(Predicate<T>， 
以 便于 条 件 性 地 停止 消费 事件 














T 











添加 使 用 buffersize 和 delayError 选项 的 重 载 版 本 ， 





映射 版 本 未 列 入 RC1 
RC3 返回 Completable 
RC3 返回 Single<Boolean> 

















RC3 重 命 名 为 lastElement 并 返 








废弃 ， 重 命名 为 filter(predica 








[Consumer<Throwable>, [Action]]), 








定义 的 内 部 




















回 Maybe<T> 
te).Last() 


重 命 名 为 last(T)，RC3 返回 Single<T> 


废弃 ,使 用 filter(predicate).last(T) 


废弃 ， 使 用 手动 just 
添加 带 有 prefetch 的 重 载 形式 
RC3 返回 Maybe<T> 




















添加 reduceWith(Callable，BiFunction)， 以 单个 Subscriber 的 方式 











减少 ， 返 回 Single<T> 








添加 repeatUntil(BooleanSupplier) 
废弃 该 重 载 形式 ， 使 用 subscribeOn(Scheduler).repeatWhen (Function) 








替代 


添加 retry(Predicate)、retry(int, Predicate) 


添加 retryUntil(BooleanSupplier) 
废弃 该 重 载 形 式 ， 使 用 subscribeOn(Scheduler).retryWhen (Function) 

















替代 


如 果 上 游 流 在 这 个 时 间 段 内 结束 ， 不 会 发 布 最 后 一 个 条 目 ， 添 加 带 





有 emitLast 参数 的 重 载 形式 


添加 scanWith(CaLLabLe，BiFunction)， 基 于 


进行 扫描 











| 本 


和 个 Subscriber 的 方式 





RC3 重 命 名 为 singLeELement， 返 回 Maybe<T> 





废弃 ， 
重 命名 为 single(T)，RC3 返 巨 
废弃 ， 





























使 用 filter(predicate).single() 


SingLe<T> 


使 用 filter(predicate).single(T) 


添加 带 有 buffersize 和 deLayError 选项 的 重 载 版 本 
具有 2~9 个 参数 的 重 载 形式 已 废弃 ， 使 用 startWithArray 作为 替代 





方案 


为 了 消除 歧义 性 ， 新 增 了 startWithArray 
不 再 使 用 安全 的 包装 器 包装 所 有 消费 者 类 型 (如 0bserver)， 就 像 























1x 的 unsafeSubscribe 已 经 不 可 用 了 。 显 式 使 用 safeSubscribe 获取 





消费 者 类 型 的 安全 包装 器 
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1.X 2.X 

N/A 添加 subscribewith， 它 会 在 订阅 之 后 返回 它 的 输入 

switchMap 添加 带 有 prefetch 的 重 载 形 式 

SwitchMapDeLayError 添加 带 有 prefetch 的 重 载 形 式 

takeLastBuffer 废弃 

N/A 添加 test() (返回 订阅 它 的 TestSubscriber)， 具 有 重 载 形 式 以 便于 
流畅 地 测试 

throttleLast 如 果 在 这 段 时 间 内 上 游 流 结束 ， 不 会 发 布 最 后 一 个 条 目 ， 请 使 用 带 
有 emitLast 参数 的 sample 


timeout(Func0<Observable>, 


toBlocking().y 
toCompletable 
toList 

toMap 
toMultimap 
N/A 

N/A 

toSingle 
toSortedList 


unsafeSubscribe 


withLatestFrom 


zipWith 


口 各 种 返回 类 型 〈( 见 表 C-3) 








签名 更 改 为 timeout(Publisher， 
请 使 用 defer(CaLLabLe<PubLisher>>) 

内 联 为 blockingY() 操作 符 ，toFuture 除外 
RC3 已 废弃 ， 使 用 ignoreElements 











RC3 返 匠 
RC3 返 匠 
RC3 返回 
添加 toFuture 

















Single<List<T>> 


Single<Map<K, V>> 


添加 toObservable 





RC3 已 废弃 ,使 





用 single(T) 


RC3 返回 Single<List<T>> 








情况 下 在 subscr 


ibe 上 





)， 废 弃 了 国 数 。 如 果 必 要 的 话 ， 


Single<Map<K, Collection<V>>> 





法 会 围绕 消费 者 类 型 显 式 添加 一 个 安全 包装 器 
废弃 5~9 个 源 的 重 载 形式 


添加 带 有 prefetch 和 delayErrors 选项 的 重 载 形 





在 2x 中 ， 有 些 只 生成 一 个 值 或 者 会 产生 错误 的 操作 符 现 在 会 


事件 源 ， 那 么 会 返回 Maybe)。 








意 ， 这 在 RC2 和 RC3 中 是 “实验 性 的 ”， 
， 以 及 是 否 需 要 太 多 to0bservable/toFlowable 的 反 向 转换 。) 


表 C-3: 各 种 返回 类 型 














NN 
间 


已 移 除 ， 因 为 反应 式 规范 要 求 onXXx 方法 不 能 出 现 月 溃 ， 
ph 没有 安全 网 的 保护 。 新 增 的 safesubscribe 方 


所 以 默认 


返回 Singte (如 果 允 许 空 的 





目的 是 了 解 使 月 


有 这 种 混合 


类 型 序列 编程 的 感 
































操 作 符 旧 的 返回 类 型 新 的 返回 类 型 ” 备 注 

all(Predicate) Observable<Boolean> Single<Boolean> 如 果 所 有 元 素 均 匹配 断言 ， 发 布 
true 

any(Predicate) Observable<Boolean> Single<Boolean> 如 果 任 意 一 个 元 素 均 匹 配 断 言 ， 
发 布 true 

count() Observable<Long> Single<Long> 统计 序列 中 元 素 的 数量 
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操 作 符 旧 的 返回 类 型 新 的 返回 类 型 备 注 
elementAt(int) Observable<T> Maybe<T> 发 布 给 定 索 引 的 元 素 ， 或 者 直接 
完成 
elementAt(int, T) Observable<T> Single<T> 发 布 给 定 索 引 的 元 素 或 默认 值 
elementAtOrError(int) Observable<T> Single<T> 发 布 给 定 索 引 的 元 素 或 
NoSuchElementException 
first(T) Observable<T> Single<T> 发 布 第 一 个 元 素 或 
NoSuchElementException 
firstElement() Observable<T> Maybe<T> 发 布 第 一 个 元 素 ， 或 者 直接 完成 
firstOrError() Observable<T> Single<T> 发 布 第 一 个 元 素 ， 如 果 源 为 空 ， 
抛 出 NoSuchElementException 
ignoreElements() Observable<T> Completable 忽略 除 终 端 事件 之 外 的 所 有 内 容 
isEmpty() Observable<Boolean> Single<Boolean> 如 果 源 为 空 ， 发 布 true 
Last(T) Observable<T> Single<T> 发 布 最 后 一 个 元 素 或 默认 值 
LastELement() Observable<T> Maybe<T> 发 布 最 后 一 个 元 素 或 直接 完成 
LastorError() Observable<T> Single<T> 发 布 最 后 一 个 元 素 ， 如 果 源 为 空 ， 
抛 出 NoSuchElementException 
reduce(BiFunction) Observable<T> Maybe<T> 发 布 约 减 后 的 值 或 直接 完成 
reduce(Callable, BiFunction) Observable<U> Single<U> 发 布 约 减 后 的 值 (或 初始 值 ) 
reduceWith(U, BiFunction) Observable<U> Single<U> 发 布 约 减 后 的 值 (或 初始 值 ) 
single(T) Observable<T> Single<T> 返回 唯一 的 元 素 或 默认 值 
singleElement() Observable<T> Maybe<T> 返回 唯一 的 元 素 或 直接 完成 
singleOrError() Observable<T> Single<T> 返回 有 且 仅 有 的 一 个 元 素 ， 
如 果 源 的 长 度 超过 1 个 条 
目 ， 抛 出 IndexoutOfBounds- 
Exception; 如 果 源 为 空 ， 抛 出 
NoSuchElementException 
toList() Observable<List<T>> Single<List<T>> 将 所 有 的 元 素 收 集 到 一 个 List 中 
toMap() Observable<Map<K, Single<Map<K, V>> 将 所 有 的 元 素 收 集 到 一 个 Map 中 
V>> 
toMultimap() Observable<Map<K, Single<Map<K, 将 所 有 的 元 素 收集 到 一 个 带 有 集 
Collection<V>>> Collection<V>>> ” 合 的 Map 中 
toSortedList() Observable<List<T>> Single<List<T>> 将 所 有 的 元 素 收 集 到 一 个 List 
中 并 排序 
口 移 除 


为 了 确保 2.0 版 本 的 最 终 API 尽 可 能 地 简洁 ， 我 们 移 除 了 候选 发 布 版 本 之 间 的 方法 和 其 他 
组 件 ， 而 不 是 反对 他 们 ( 见 表 C-4)。 
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表 C-4: 移 除 与 替代 



































在 版 本 中 移 除 组 ” 件 合计 : 

RC3 Flowable. toCompletable() 使 用 Flowable.toCompletable() 
RC3 Flowable. tosingle() 使 用 Flowable.single(T) 

RC3 Flowable. toMaybe( ) 使 用 Flowable.single(T) 

RC3 Observable.toCompletable() 使 用 Observable.ignoreElements() 
RC3 Observable. tosingle() 使 用 Observable.tosSingle() 

RC3 Observable. toMaybe() 使 用 Observable.singleElement() 











C.1.23 杂项 变 


do0nCanceL/do0nDispose/unsubscribeon 

在 1x 中 遇 到 终端 事件 时 ，doOnUnsubscribe 始终 都 会 执行 ， 因 为 1x 的 SafeSsubscriber 本 
身 就 会 调用 unsubscribe。 这 实际 上 是 设 有 必要 的 。 反 应 式 规范 规定 如 果 某 个 终端 事件 抵达 
Subscriber， 上 游 Subscription 应 该 视 为 已 经 取消 ， 因 此 调用 cancel() 就 没有 什么 意义 了 。 
基于 相同 的 原因 ， 在 常规 的 终端 路 径 中 ，unsubscribeon 不 会 被 调用 ， 只 有 实际 调用 
cancel (或 dispose) 的 时 候 ， 才 会 调用 这 个 链 。 


因此 ， 如 下 序列 不 会 调用 doonCancel。 


Flowable.just(1, 2, 3) 
.do0nCanceL(() -> System.out.println("Cancelled!")) 
.Subscribe(System.out::println); 


但 是 ， 如 下 代码 会 调用 doonCancel， 因 为 take 操作 符 在 指定 数量 的 onNext 
后 会 取消 订阅 。 

Flowable.just(1, 2, 3) 

.do0nCanceL(() -> System.out.println("Cancelled!")) 


.take(2) 
.subscribe(System.out: :println); 


如 果 需 要 在 正常 的 终端 或 取消 场景 下 执行 一 些 清理 操作 ， 那 么 可 以 浪 虑 使 用 using 作为 替 
代 方 案 。 

另外 ， 还 可 以 考虑 使 用 doFinally 操作 符 (2.0.1 版 本 引入 ，2.1 版 本 中 进行 了 标准 化 )。 它 
会 在 源 完成 的 时 候 调 用 开发 人 员 指 定 的 Actton， 无 论 是 因为 错误 而 失败 还 是 因为 执行 了 


cancel/dispose, 

















hl 





EE 件 被 投递 之 


. 

















Flowable.just(1, 2, 3) 
.doFinally(() -> System.out.println("Finally")) 
.Subscribe(System.out::println); 


Flowable.just(1, 2, 3) 
.doFinally(() -> System.out.println("Finally")) 
.take(2) // 在 2 个 元 素 之 后 消去 上 面 的 项 


.Subscribe(System.out::println); 
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C.2 RxJava 2.0 版 本 中 的 回 压 


C.2.1 回 压 概述 

回 压 是 指 在 Flowable 处 理 管道 上 ， 一 些 异 步 的 处 理 阶 段 无 法 快速 地 处 理 值 ， 因 此 需要 有 一 
种 方式 来 通知 上 游 生 产 者 放 慢 速度 。 

需要 回 压 功能 的 典型 场景 (生产 者 为 hot 类 型 的 源 时 ) 如 下 所 示 。 


Publishprocessor<Integer> source = PubLishProcessor .create(); 
































source 
.ObserveOn(Schedulers.computation()) 
.Subscribe(v -> compute(v), Throwable::printStackTrace); 


for (int i = 0; i < 1 000 000; i+t+) { 
source.onNext(i); 


} 
Thread.sleep(10_000); 


在 本 例 中 ， 主 线程 会 为 终端 消费 者 生成 100 万 个 条 目 ， 消 费 者 会 在 后 台 线 程 中 对 它们 进行 
处 理 。compute(int) 方法 可 能 会 耗费 一 些 时 间 ，Flowable 操作 符 链 可 能 也 会 添加 用 于 条 目 
处 理 的 时 间 。 但 是 ， 具 有 for 循环 的 生成 线程 并 不 知道 这 一 点 ， 会 不 断 调用 onNext。 


在 内 部 ， 异 步 操 作 符 有 一 个 缓冲 区 来 存放 这 样 的 元 素 ， 直 到 它们 得 到 处 理 。 在 经 典 的 
Rx.NET 和 早期 的 RxJava 中 ， 这 些 缓 冲 区 没有 边界 限制 ， 即 在 本 例 中 会 存放 近 100 万 个 条 
目 。 如 果 在 程序 中 有 10 亿 个 元 素 或 相同 的 100 万 个 序列 出 现 了 1000 次 ， 那 么 问题 就 出 现 
了 ， 这 会 导致 QutofMemoryError， 通 常 还 会 因为 过 多 的 GC 开销 导致 系统 变 慢 。 

在 RxJava 中 ， 错 误 处 理 是 一 等 公民 ， 并 且 会 使 用 操作 符 对 其 进行 处 理 (通过 onErrorXXX)。 
与 之 类 似 ， 回 压 是 开发 人 员 必 须要 考虑 的 数据 流 另 一 个 属性 (通过 onBackpressureXXX 操 
作 符 )。 


除了 上 面 提 到 的 PublishProcessorabove， 还 有 其 他 操作 符 不 支持 回 压 ， 这 大 多 数 是 功能 
面 的 原因 。 例 如 ， 操 作 符 interval 会 周期 性 地 发 布 值 ， 如 果 对 其 实施 回 压 ， 会 导致 时 间 段 
相对 于 墙 上 时 钟 (wall clock) 产生 偏差 。 


在 现代 RxJava 中 ， 大 多 数 异 步 操 作 符 都 有 一 个 有 界 的 内 部 缓冲 ， 比 如 上 面 提 到 的 observeon。 
如 果 尝 试 洪 出 这 个 缓冲 区 ， 整 个 序列 将 会 终止 ,并且 会 抛 出 MissingBackpressureException。 
每 个 操作 符 的 文档 都 有 关于 回 压 行为 的 描述 。 
但 是 ， 在 常规 cold 类 型 的 序列 中 ， 回 压 的 行为 更 微妙 一 些 ( 它 不 会 也 不 应 该 产生 
MissingBackpressureException)。 如 果 将 第 一 个 样 例 重 写 为 以 下 代码 。 

Flowable.range(1, 1_000_000) 


.ObserveOn(Schedulers.computation()) 
.Subscribe(v -> compute(v), Throwable::printStackTrace); 









































































































































Thread.sleep(10_000); 





RxJava 1.0 至 RxJava 2.0 的 迁移 指南 | 295 


这 里 不 会 出 现任 何 错误 ， 程 序 能 够 以 很 少 的 内 存 占 用 平稳 运行 。 原 因 在 于 很 多 源 操作 符 能 
够 按照 需求 “生成 ” 值 。 因 此 ，observeon 操作 符 告 诉 range 最 多 要 生成 多 少 值 ， 才 能 确保 
observeon 缓冲 区 可 以 立刻 容纳 而 不 出 现 滋 出 。 


这 个 协商 的 过 程 基于 计算 机 科学 中 的 协 程 概念 (co-routine， 我 调用 你 ， 你 调用 我 )。 操 
作 符 range 发 送 一 个 回调 给 observe0n， 这 个 回调 的 表现 形式 是 org.reactivestreams . 
Subscription 接口 的 实现 ， 从 而 能 够 调用 它 的 (内 部 Subscriber 的 ) onSubscribe。 反 过 
来 ，observeon 调用 Subscription.request(n)， 调 用 时 带 有 一 个 值 以 告诉 range 允许 生成 
( 即 调用 其 onNext) 的 额外 元 素数 量 。 随 后 ，observeon 负责 在 合适 的 时 间 以 合适 的 值 调用 
request 方法 ， 以 确保 数据 正常 流动 ， 不 会 出 现 溢出 的 情况 。 


终端 消费 者 很 少 需 要 表述 回 压 (因为 它们 与 直接 上 游 同 步 ， 而 回 压 是 调用 栈 阻塞 而 自然 发 
生 的 )， 但 是 这 样 做 可 以 更 容易 地 理解 它 的 运行 原理 ， 如 下 所 示 。 


Flowable.range(1, 1_000_000) 
.Subscribe(new DisposableSubscriber<Integer>() { 
@Override 
public void onStart() { 
request(1); 
















































































} 


public void onNext(Integer v) { 
compute(v); 


request(1); 


@Override 
public void onError(Throwable ex) { 
ex.printStackTrace(); 


} 


@Override 
public void onComplete() { 
System.out.println("Done!"); 
} 
]); 


onStart 告诉 range 生成 其 第 一 个 值 ， 然 后 在 onNext 中 接收 该 值 。 一 旦 compute(int) 完 
成 ， 程 序 就 会 从 range 中 请 求 另外 一 个 值 。 在 range 的 原生 实现 中 ， 这 样 的 代码 会 递归 调 
用 onNext， 从 而 出 现 StackoverfLowError， 这 当然 是 我 们 不 想 看 到 的 。 


为 了 避免 出 现 这 种 情况 ， 操 作 符 使 用 了 所 谓 的 蹦床 逻辑 (trampolining logic) 来 避免 这 种 
可 重 入 调用 。 就 range 来 说 ， 它 会 记 住 在 调用 onNext() 时 有 一 个 request(1) 调用 , 一旦 
onNext() 返回 ， 它 就 会 发 起 新 一 轮 的 调用 ， 并 使 用 下 一 个 整数 值 来 调用 onNext()。 因 此 ， 
如 果 两 行 代码 互 换 位 置 ， 样 例 依 然 能 够 以 相同 的 方式 运行 ， 如 下 所 示 。 

@Override 


public void onNext(Integer v) { 
request(1); 
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Compute(v); 


} 
但 是 ，onStart 的 情况 并 非 如 此 。 尽 管 Flowable 的 基础 设施 能 够 确保 在 每 个 Subscriber 
上 最 多 只 调用 一 次 ， 对 request(1) 的 调用 可 能 会 立即 触发 元 素 的 发 布 。 如 果 在 调用 
request(1) 后 面 有 onNext 需要 的 初始 化 逻辑 ， 那 么 可 能 会 出 现 异 常 。 


Flowable.range(1, 1_000_000) 
.Subscribe(new DisposableSubscriber<Integer>() { 





String name; 


@Override 
public void onStart() { 
request(1); 


name = "RangeExample"; 


} 


@Override 
public void onNext(Integer v) { 
compute(name.length + v); 


request(1); 


1/…… 剩 余 内 容 是 相同 的 

}); 
在 这 个 同步 的 场景 中 ， 执 行 onStart 的 时 候 会 立即 抛 出 NullPointerException。 如 果 对 
request(1) 的 调用 触发 了 其 他 线程 上 对 onNext 的 异步 调用 ， 在 onNext 中 读 取 nanme 与 在 
onStart 中 写 入 name 竞争 公布 request， 这 样 可 能 会 产生 更 诡异 的 bug。 
因此 ， 我 们 应 该 在 onstart 或 更 早 的 地 方 完成 所 有 字段 的 初始 化 ， 最 后 再 调用 request()。 
如 果 必 要 ， 操 作 符 中 的 request() 实现 要 确保 正确 的 happens-before 关系 〈 即 内 存 释放 或 
完全 隔离 )。 





















































C.2.2 onBackpressureXXx 操 作 符 

在 应 用 程序 因为 MissingBackpressureException 而 失败 时 ， 大 多 数 开 发 人 员 就 会 接触 
到 回 压 ， 异 常 通常 指向 observeon 操作 符 。 实 际 的 诱因 通常 是 使 用 了 不 支持 回 压 的 
PublishpProcessor、timer() 或 intervaL()， 或 是 通过 create() 创建 的 自 定义 操作 符 。 

我 们 有 多 种 方式 来 处 理 这 样 的 场景 。 

1. 增加 缓冲 区 的 大 小 

有 了 时候 ， 这 样 的 溢出 是 由 突 发 的 源 引 起 的 。 比 如 ， 用 户 突然 快速 地 点 击 屏幕 ，observeOn 
在 Android 中 默认 的 存放 16 个 元 素 的 缓冲 区 就 会 溢出 。 

在 最 近 的 RxJava 版 本 中 ， 大 多 数 对 回 压 敏感 的 操作 符 都 能 够 让 开发 人 员 指 定 其 内 部 缓冲 
区 的 大 小 。 相 关 的 参数 通常 被 称 为 buffersize、prefetch 或 capacityHint。 基 于 概述 中 的 
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样 例 ， 我 们 可 以 增加 observeon 的 大 小 ， 让 它 有 足够 的 空间 存放 所 有 的 值 。 


Publishprocessor<Integer> source = Publishprocessor.create(); 














source.observeOn(Schedulers.computation(), 1024 * 1024) 
.Subscribe(e -> { }, Throwable::printStackTrace); 


for (int i = 0; i < 1 000 000; i++) { 
source.onNext(i); 


} 


不 过 ， 需 要 注意 ， 这 只 是 临时 的 修复 方法 ， 如 果 源 超出 了 预计 的 缓 站 
溢出 的 情况 。 这 时 ， 我 们 可 以 在 下 面 这 些 操作 符 中 选择 一 个 使 用 。 


2. 使 用 标准 的 操作 符 批 处 理 或 跳 过 值 


= 























区 大 小 ， 依 然 会 发 生 


如 果 源 数据 能 够 按照 批 次 更 高 效 地 进行 处 理 ， 那 么 可 以 使 用 标准 的 批 处 理 操作 符 〈 按 照 大 





小 或 时 间 进 行 批 量 处 理 ), 减少 MissingBackpressureException 出 现 的 可 能 性 。 


Publishprocessor<Integer> source = Publishprocessor.create(); 


source 
.buffer(1024) 
.observeOn(Schedulers.computation(), 1024) 
.Subscribe(list -> { 
list.parallelStream().map(e -> e * e).first(); 
}, Throwable::printStackTrace); 


for (int i = 0; i < 1 000 000; i++) { 
source.onNext(i); 


} 





如 果 可 以 安全 地 忽略 某 些 值 ， 那 么 我 们 可 以 使 用 采样 (基于 时 间或 男 一 个 Flowable 进行 采 











样 ) 或 者 节 流 操作 符 (throttleFirst、throttleLast、throttlewithTimeout)。 


Publishprocessor<Integer> source = Publishprocessor.create(); 


source 
.Sample(1, TimeUnit.MILLISECONDS) 
.ObserveOn(Schedulers.computation(), 1024) 
.Subscribe(v -> compute(v), Throwable::printStackTrace); 


for (int i = 0; i < 1 000 000; i++) { 
source.onNext(i); 
} 
注意 ， 这 些 操 作 符 只 是 降低 了 下 游 接收 值 的 速度 ， 


pressureException, 








Ba 


I 




















3. onBackpressureBuffer() 


此 依然 有 可 能 会 出 现 MissingBack- 


这 个 操作 符 的 无 参 形 式 会 在 上 游 源 和 下 游 操 作 符 之 间 重 新 引入 一 个 无 界 的 缓冲 区 。 无 界 意 


味 着 只 要 JVM 没有 耗 尽 内 存 ， 它 就 能 处 理 来 自 突 发 源 的 任意 数量 的 事件 。 
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Flowable.range(1, 1_000_000) 
.OnBackpressureBuffer() 
.ObserveOn(Schedulers.computation(), 8) 
.Subscribe(e -> { }, Throwable::printStackTrace); 





在 本 例 中 ，observeon 的 缓冲 区 非常 小 ， 但 是 不 会 出 现 MissingBackpressureException。 
为 onBackpressureBuffer 会 吸收 所 有 的 100 万 个 值 ， 并 将 其 以 很 小 的 批 次 传递 给 


observeOn。 


但 是 需要 注意 ， onBackpressureBuffer 以 无 界 的 形式 消费 它 的 源 ， 这 意味 着 它 不 会 应 用 任 
何 回 压 。 其 结果 是 ， 即 使 是 range 这 样 的 回 压 支撑 源 也 将 完全 实现 。 


onBackpressureBuffer 有 4 种 额外 的 重 载 形式 。 


9 onBackpressureBuffer(int capacity) 
这 是 一 个 有 界 的 版 本 ， 如 果 缓 冲 区 达到 指定 容量 ， 将 发 布 Buffer0verfLowErrorin。 


Flowable.range(1, 1_000_000) 
.OnBackpressureBuffer(16) 
.observeOn(Schedulers.computation()) 
.Subscribe(e -> { }, Throwable::printStackTrace); 


越 来 越 多 的 操作 符 可 以 设置 缓冲 区 的 大 小 ， 这 个 操作 符 的 重要 性 在 不 断 下 降 。 其 他 场景 
中 ， 将 onBackpressureBuffer 设置 为 比 默认 值 更 大 的 数字 其 实 是 给 了 操作 符 一 个 “扩展 内 
部 缓冲 区 ”的 机 会 。 

口 onBackpressureBuffer(int capacity, Action onOverflow) 

这 个 重 载 形式 会 在 溢出 时 调用 一 个 〈 共 享 的 ) 操作 。 它 的 用 途 非 常 有 限 ， 除 了 当前 的 调用 
栈 之 外 ， 无 法 提供 关于 溢出 的 其 他 信息 。 


口 onBackpressureBuffer(int capacity, Action onOverflow, BackpressureOverf lowStrategy 
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个 重 载 形式 更 有 用 ， 我 们 可 以 定义 在 达到 给 定 的 容量 时 要 执行 什么 操作 。 
A 实际 上 是 一 个 接口 ， 但 是 BackpressureOverflow 提供 了 4 
个 静态 的 域 ， 这 些 域 的 实现 代表 典型 的 操作 。 


。 ”ON_OVERFLOW_ERROR: 这 是 前 两 个 重 载 的 默认 行为 ， 显 示 一 个 BufferOverflowException。 
。 ON_OVERFLOW_DEFAULT: 现在 它 和 ON_OVERFLOW_ERROR 一 样 。 
。 ”ON_OVERFLOW_DROP_LATEST: 如 果 发 生 溢出 ， 当 前 的 值 会 直接 被 忽略 ， 仅 在 下 游 请 求 时 才 
会 传递 旧 值 。 
。 0ON_OVERFLOW_DROP_0LDEST: 删除 缓冲 区 中 的 最 旧 的 元 素 并 向 其 中 添加 当前 值 。 
Flowable.range(1, 1_000_000) 
.OnBackpressureBuffer(16，() -> { }, 
BufferOverflowStrategy .ON_OVERFLOW_DROP_OLDEST) 


.observeOn(Schedulers.computation()) 
.Subscribe(e -> { }, Throwable::printStackTrace); 


主意 ， 最 后 两 种 策略 会 导致 流 的 不 连续 ， 因 为 它们 会 丢弃 元 素 。 另 外 ， 它 们 不 会 标记 


De es 
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口 onBackpressureDrop() 
下 游 不 再 准备 接收 值 的 时 候 ， 这 个 操作 符 会 丢弃 序列 中 的 元 素 。 我 们 可 以 将 其 视 为 : 容 
为 0 的 onBackpressureBuffer， 策 略为 ON_OVERFLOW_DROP_LATEST。 


如 果 我 们 可 以 安全 地 忽略 源 中 的 元 素 (比如 鼠标 移动 或 当前 GPS 位 置 的 信号 ) ， 那 么 这 
操作 符 就 有 了 用 武之 地 ， 因 为 随后 会 有 更 多 的 新 值 出 现 。 


component .mouseMoves() 

.OnBackpressureDrop() 
.ObserveOn(Schedulers.computation(), 1) 
.Subscribe(event -> compute(event.x, event.y)); 


它 还 可 以 与 源 操作 符 interval() 组 合 起 来 使 用 。 例 如 ， 如 果 我 们 想 要 执行 一 些 周 期 性 的 后 
台 任 务 ， 但 是 每 次 迭代 比 周 期 还 长 ， 此 时 可 以 安全 地 丢弃 多 余 的 间隔 通知 ， 因 为 随后 会 出 
现 更 多 的 通知 。 


Flowable.interval(1, TimeUnit.MINUTES) 
.oNnBackpressureDrop() 

.observeOn(Schedulers.io()) 

.do0nNext(e -> networkCall.doStuff()) 
.Subscribe(v -> { }, Throwable::printStackTrace); 


难 
地 



























































这 个 操作 符 有 一 个 重 载 形 式 : onBackpressureDrop(Consumer<? super T> onDrop)。 值 要 被 
丢弃 的 时 候 ， 会 调用 这 个 〈 共 享 的 ) 操作 。 该 变种 形式 能 够 让 我 们 对 值 本 身 进行 一 些 清理 
(比如 释放 相关 的 资源 )。 
DD onBackpressureLatest() 
最 后 一 个 操作 符 只 会 保留 最 后 一 个 值 ， 将 更 旧 的 、 未 投递 的 值 履 盖 。 我 们 可 以 将 其 视 为 
onBackpressureBuffer 的 一 个 变 体 : 容量 为 1， 策略 为 ON_OVERFLOW_DROP_OLDEST。 
不 同 于 onBackpressureDrop，onBackpressureLatest 能 够 确保 下 游 的 处 理 速度 跟 不 上 节奏 
时 ， 始 终 还 有 一 个 值 可 以 被 消费 。 在 一 些 类 似 遥 测 的 场景 中 ， 这 种 方式 可 能 会 非常 有 用 ， 
这 时 数据 可 能 会 以 突 发 模式 出 现 ， 但 是 只 有 最 新 的 值 才 值 得 处 理 。 
例如 ， 如 果 用 户 在 屏幕 上 点 击 了 多 次 ， 我 们 只 会 对 最 后 的 输入 做 出 响应 。 
Component .mouseCLicks() 
.OnBackpressureLatest() 


.observeOn(Schedulers.computation()) 
.Subscribe(event -> compute(event.x, event.y), Throwable::printStackTrace); 


如 果 在 这 里 使 用 onBackpressureDrop， 会 导致 最 后 的 点 击 被 丢弃 ， 用 户 可 能 会 奇怪 为 什么 
业务 逻辑 没有 执行 。 


C.2.3 创建 支持 回 压 的 数据 源 


在 处 理 回 压 相关 的 问题 时 ， 创 建 支持 回 压 的 数据 产 相 对 容易 ， 因 为 库 已 经 在 Flowable 上 提 
供 了 处 理 回 压 的 静态 方法 。 我 们 可 以 将 工厂 方法 分 为 两 类 : cold 类 型 的 “生成 器 ”( 它 能 
够 基于 下 游 的 需求 返回 或 生成 元 素 ) 和 hot 类 型 的 “推送 器 ”( 它 通常 会 将 非 反 应 式 和 /或 
不 支持 回 压 的 数据 源 桥接 起 来 ， 在 它们 之 上 添加 一 个 处 理 回 压 的 层 )。 
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1. just 
最 简单 的 能 够 感知 回 压 的 源 可 以 通过 just 创建 ， 如 下 所 示 。 


Flowable.just(1).subscribe(new DisposableSubscriber<Integer>() { 
@Override 
public void onStart() { 
request(0); 





} 


@Override 
public void onNext(Integer v) { 
System.out.println(v); 


} 


// 为 了 保持 简洁 ， 略 去 了 剩余 内 容 
} 


因为 我 们 在 onstart 中 显 式 不 请 求 任何 值 ， 这 里 不 会 打印 出 任何 内 容 。 如 果 我 们 想 要 为 党 
量 值 启动 一 个 序列 ， 那 么 just 是 非常 有 用 的 。 


但 是 ，just 经 常 被 误 认 为 动态 计算 Subscriber 消费 的 一 种 方式 。 


int counter ; 








int computeValue() { 
return ++counter; 


} 
Flowable<Integer> 0 = Flowable.just(computeValue()); 


o.subscribe(System.out:println); 
o.subscribe(System.out:println); 


可 能 会 出 乎 一些 人 的 预料 ， 这 里 会 打印 两 次 1， 而 不 是 分 别 打 印 出 1 和 2。 如 果 我 们 重 写 
一 下 调用 方式 ， 其 运行 方式 就 会 更 加 明显 。 


int temp = computeValue(); 











FLowabLe<Integer> 0 = Flowable.just(temp); 
computeValue 是 主 例 程 调用 的 一 部 分 ， 而 不 在 对 订阅 者 的 订阅 操作 的 响应 中 。 
2. fromCallable 
我 们 真正 需要 的 是 fromCallable。 
Flowable<Integer> o = Flowable.fromCallable(() -> computeValue()); 
在 这 里 ， 只 有 每 个 订阅 者 都 订阅 的 时 候 ，computeValue 才 会 执行 ， 分 别 打印 出 1 和 2。 显 
然 ，fromCallable 能 够 很 好 地 支持 回 压 ， 除 非 请 求 值 ， 否 则 它 不 会 发 布 计算 后 的 值 。 但 是 


需要 注意 ， 无 论 如 何 计算 都 会 发 生 。 如 果 计 算 本 身 应 该 延迟 到 下 游 真正 请 求 时 才 执 行 ， 我 
们 可 以 组 合 使 用 just 和 map。 


Flowable.just("This doesn't matter").map(ignored -> ComputeVaLue())... 
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在 真正 请 求 之 前 ，just 不 会 发 布 它 的 常量 值 ， 只 有 在 请 求 的 时 候 ， 它 才 会 映射 为 computeValue 
的 结果 ， 此 时 依然 会 为 每 个 订阅 者 分 别 调用 。 
3. fromArray 


如 果 数 据 已 经 能 够 以 对 象 数组 、 对 象 列 表 或 Iterable 源 的 形式 获取 ， 那 么 对 应 的 from 重 
载 形 式 将 会 处 理 回 压 和 这 类 源 的 发 布 。 


Flowable.fromArray(1, 2, 3, 4, 5).subscribe(System.out::println); 


为 方便 起 见 (同时 避免 泛 型 数组 创建 的 告警 )，just 有 2 到 10 个 参数 的 重 载 形式 ， 它 们 内 
部 都 将 功能 委托 给 了 from。 


fromIterable 也 创造 了 一 个 很 有 意思 的 机 会 。 很 多 值 的 生成 都 能 以 状态 机 的 形式 表述 。 每 
个 元 素 请 求 都 会 触发 状态 的 转换 ， 并 计算 返回 值 。 
将 这 样 的 状态 机 编写 成 Iterable 比较 复杂 (不 过 依旧 比 编写 成 一 个 Flowable 来 消费 它 简 
单一 些 )， 而 且 与 C# 不同 ，Java 并 没有 从 编译 器 层面 对 构建 这 种 状态 机 提供 支持 ， 即 经 
典 风 格 的 代码 (使 用 yield return 和 yield return)。 有 些 库 能 够 提供 一 些 帮助 ， 比 如 
Google Guava 的 AbstractIterable 和 IxJava 的 Ix.generate() 与 Ix.forloop()。 这 些 内 容 
本 身 就 值得 写 一 个 完整 的 系列 ， 以 下 是 非常 基础 的 Iterable 源 ， 可 以 无 限 重复 地 生成 某 个 


三 阅 


有 币 量 。 









































IterabLe<Integer> iterable = () -> new Iterator<Integer>() { 
@Override 
public boolean hasNext() { 
return true; 


} 


@Override 
public Integer next() { 
return 1; 
} 
}; 


Flowable.fromIterable(iterable).take(5).subscribe(System.out::println); 


如 果 我 们 通过 经 典 的 for 循环 使 用 iterator， 将 导致 无 限 循环 。 但 是 我 们 在 它 的 外 部 构建 
了 一 个 Flowable， 可 以 表达 只 消费 前 5 个 流 的 意愿 ， 然 后 停止 请 求 任何 内 容 。 这 就 是 在 
Flowable 内 部 延迟 执行 和 计算 的 真正 威力 。 

4. generate() 

有 时 候 ， 要 转换 到 反应 式 领 域 的 数据 源 本 身 是 同步 (阻塞 式 ) 和 拉 取 类 型 的 ， 换 言 之 ， 我 
们 需要 调用 get 或 read 方法 才能 获取 下 一 块 数据 。 当 然 可 以 将 其 转换 为 一 个 Iterable， 
但 是 这 种 源 与 资源 关联 的 时 候 ， 如 果 下 游 在 序列 完成 之 前 就 取消 订阅 ， 可 能 会 造成 资源 
为 了 处 理 这 种 问题 ，RxJava 提供 了 generate 工厂 方法 家 族 。 


Flowable<Integer> 0 = Flowable.generate( 
() -> new FileInputStream("data.bin"), 
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(inputstream, output) -> { 
try { 
int abyte = inputstream.read(); 
if (abyte < 0) { 
output .onCompLete() ; 
} else { 
output .onNext(abyte); 


} catch (IOException ex) { 
output .onError(ex); 


} 
return inputstream; 
]， 
inputstream -> { 
try { 
inputstream.close(); 
} catch (IOException ex) { 
RxJavaPlugins.onError(ex); 
} 
} 


); 
一 般 情况 下 ，generate 会 使 用 3 个 回调 。 


第 一 个 回调 能 够 创建 每 个 订阅 者 的 专 有 状态 ， 比 如 本 例 中 的 FileInputStream， 每 个 订阅 者 
均 会 独立 地 打开 该 文件 。 


第 二 个 回调 接收 这 个 状态 对 象 ， 并 且 提 供 一 个 输出 Observer， 可 以 调用 它 的 onXXX 方法 来 
发 布 值 。 这 个 回调 的 执行 次 数 与 下 游 请 求 次 数 相同 。 在 每 次 调用 的 时 候 ， 它 最 多 调用 一 次 
onNext， 然 后 紧 跟着 onError 或 onCompLete。 在 本 例 中 ， 如 果 读 取 字 节 为 负数 ， 我 们 会 调 
用 onComptLete()， 表 明文 件 的 结束 ， 如 果 读 取 抛 出 IOException， 会 调用 onError。 


在 下 游 取 消 订 阅 (关闭 输入 流 ) 或 者 在 前 面 的 回调 调用 终端 方法 时 ， 最 后 一 个 回调 被 调 
用 。 它 可 以 对 资源 进行 释放 ， 因 为 并 非 所 有 的 源 都 需要 这 些 特性 ， 所 以 静态 的 Flowable. 
generate 方法 允许 我 们 不 考虑 这 些 创建 实例 。 


令 人 遗憾 的 是 ， 很 多 方法 调用 会 跨越 JVYM， 其 他 库 会 抛 出 检查 型 异常 。 需 要 将 其 包装 到 
try-catch 中 ， 因 为 这 个 类 使 用 的 函数 式 接口 不 可 以 抛 出 检查 型 异常。 


当然 ， 我 们 也 可 以 使 用 它 模 拟 其 他 典型 的 产 ， 比 如 无 界 的 范围 。 


FLowabLe.generate( 
() -> 0 
(current, output) -> { 
output.onNext(current); 
return current + 1; 












































让 




















]， 
e->{} 
); 
在 上 面 的 代码 中 ，current 从 9 开始，lambda 表达 式 下 次 被 调用 的 时 候 ，current 参数 存放 
的 值 为 1。 (备注 : 1.x 类 SyncOnSubscribe 和 AsyncOnSubscribe 不 再 可 用 。) 



































RxJava 1.0 至 RxJava 2.0 的 迁移 指南 | 303 


5. create(emitter) 
有 时 候 ， 需 要 使 用 Flowable 包装 的 源 已 经 是 hot 类 型 (比如 鼠标 的 移动 ) ， 或 者 虽然 是 
cold 类 型 ， 但 是 它 的 API 不 支持 回 压 (比如 异步 的 网 络 调 用 )。 


为 了 处 理 这 种 场景 ，RxJava 最 近 的 版 本 引入 了 create(emitter) 工厂 方法 。 它 会 接收 两 个 
参数 。 


。 一 个 回调 ， 针 对 每 个 传 入 的 订阅 者 都 执行 带 有 Emitter<T> 接口 的 实例 。 

。 一 个 BackpressureStrategy 枚 举 值 ， 它 会 要 求 开 发 人 员 指 定 一 个 要 使 用 的 回 压 行为 。 
它 有 常用 的 模式 ， 类 似 于 onBackpressureXXXx， 但 是 它 会 发 送 MssingBackpressure- 
Exception 或 者 简单 地 忽略 内 部 的 溢出 。 

需要 注意 ， 它 不 支持 为 这 些 回 压 模 式 指定 额外 的 参数 。 如 果 我 们 需要 自 定义 行为 ， 那 么 可 

以 使 用 NONE 回 压 模式 ， 并 在 最 终 的 Flowable 上 使 用 相关 的 onBackpressureXXX。 

它 的 第 一 个 典型 用 例 : 想 要 与 基于 推送 的 源 进行 交互 时 ， 比 如 GUI 事件 。 这 些 API 会 提供 

某 种 形式 的 addListener/removeListener 调用 以 供 我 们 使 用 。 

Flowable.create(emitter -> { 


ActionListener al = e ->{ 
emitter .onNext(e); 



















































































}; 
button.addActionListener(al); 


emitter.setCancellation(() -> 
button.removeListener(al)); 


}, BackpressureStrategy .BUFFER); 


Emitter 使 用 起 来 非常 简单 。 可 以 调用 onNext、onError 和 onComplete， 这 个 操作 符 会 自己 
处 理 回 压 和 取消 订阅 管理 。 除 此 之 外 ， 如 果 包 装 的 API 支持 取消 (比如 样 例 中 的 监听 器 移 
除 )， 那 么 我 们 可 以 使 用 setCancellation (或 Subscription 类 型 资源 的 setSubscription) 
来 注册 取消 的 回调 。 这 个 回调 会 在 下 游 取 消 订 阅 或 给 定 的 Emitter 实例 调用 onError/ 
onComplete 的 时 候 触 发 。 
这 些 方法 只 允许 emitter 与 一 个 资源 关联 ， 如 果 设 置 一 个 新 的 回调 ， 原 有 的 回调 会 自动 
取消 订阅 。 如 果 必 须要 处 理 多 个 资源 ， 那 么 可 以 创建 一 个 CompositeSubscription， 与 
emitter 关联 ， 将 更 多 的 资源 添加 到 CompositeSubscription 本 身 。 


Flowable.create(emitter -> { 
CompositeSubscription cs = new CompositeSubscription(); 




































































Worker worker = Schedulers.computation().createWorker(); 


ActionListener al =e ->{ 
emitter .onNext(e); 


}; 


button.addActionListener(al); 
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cs.add(worker); 
cs.add(Subscriptions.create(() -> 
button.removeActionListener(al)); 


emitter.setSubscription(cs); 


}, BackpressureMode .BUFFER); 


第 二 个 用 例 通 常 涉及 一 些 异 步 的 、 基 于 回调 的 API， 需 要 将 其 转换 为 Flowable。 


Flowable.create(emitter -> { 


someAPI.remoteCall(new Callback<Data>() { 
@Override 
public void onSuccess(Data data) { 
emitter .onNext(data); 
emitter .onComplete(); 


} 


@Override 
public void onFailure(Exception error) { 
emitter.onError(error); 
} 
]); 


}, BackpressureMode.LATEST); 




















可 能 会 涉及 更 复杂 的 方式 )。 注 意 ， 这 里 使 用 了 LATEST 下 





一 个 值 ， 那 么 就 不 需要 使 用 BUFFER 策略 ， 因 为 它 默 认 分 配 128 个 元 素 ( 随 


缓冲 区 ， 该 缓冲 区 永远 不 会 被 充分 利用 。 


在 这 种 情况 下 ， 代 理 按照 相同 的 方式 运行 。 但 是 ， 这 些 基于 
消 ; 不 过 ， 如 果 它 们 能 够 支持 取消 ， 我 们 就 可 以 按照 前 面 样 例 的 方式 设置 取消 功能 (当然 




















回调 风格 的 API 通常 不 支持 取 





回 压 模式 。 如 果 我 们 明确 知道 只 有 





需要 而 增长 ) 的 
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关于 作者 


托 马 什 . 努 尔 凯 维 世 (Tomasz Nurkiewicz) 是 Allegro 的 一 名 软件 工程 师 。 在 过 去 的 十 年 
里 ， 他 一 直 在 从 事 Java 编程 ， 并 且 热 爱 后 端 开发 技术 。 他 热爱 JVM 语言 和 开源 技术 。 他 
还 经 常 为 DZone 网 站 撰写 博客 ， 并 在 世界 各 地 的 Java 会 议 上 发 表演 讲 。 可 以 通过 Twitter 
账号 @tnurkiewicz 和 博客 (https://www.nurkiewicz.com/) 联系 他 。 
本 ' 克 里斯 滕 森 (Ben Christensen) 是 一 名 专注 于 弹性 、 扩 展 性 和 分 布 式 系统 的 软件 工程 
师 。 他 创建 了 满足 这 些 需求 的 开源 项 目 ， 包 括 Hystrix 和 RxJava。 


关于 封面 
本 书 封面 上 的 动物 是 集 禹 ， 又 名 南 关 狼 区 


全 钢 体 长 可 达 60 厘米 左右 ,体重 0.9~2.7 千克 。 虽 种 有 两 个 现存 物种 一 一 大 集 般 和 小 烛 
锡 ， 二 者 的 主要 区 别 在 于 体型 的 大 小 。 灶 钢 的 体 色 很 像 揣 秽 ， 和 白色 条 纹 从 前 额 一 直 延 伸 到 
脖子 后 面 ， 但 它们 比 臭 山 更 强壮 、 脖 子 更 帘 、 腿 更 短 、 尾 巴 更 小 。 

全 钢 通常 生活 在 半 开 放 的 灌木 从 和 低 海 拔 的 林地 或 森林 中 。 它 们 在 倒 下 的 树 或 岩石 裂缝 中 
筑 旭 ,主要 以 水 果 和 小 动物 为 食 。 

O’Reilly 图 书 封面 上 的 许多 动物 都 属于 濒危 物种 ， 它 们 都 是 这 个 世界 不 可 或 缺 的 一 部 分 。 
如 果 想 要 了 解 如 何 为 这 些 动物 提供 帮助 ， 请 访问 http://animals.oreilly.com。 

封面 图 片 来 自 一 幅 铅 牙 利 插图 。 
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RxJava 反 应 式 编程 


如 今 ， 移 动 App 驱 动 着 我 们 的 生活 ， 程 序 的 异步 性 和 响应 式 至 关 重 要 。 
反应 式 编程 技术 能 够 帮助 我 们 编写 易于 扩展 、 性 能 良好 且 可 靠 性 强 的 代 
码 。 在 这 本 注重 实战 的 图 书 中 ，Java 开 发 人 员 首 先 将 会 学 习 如 何以 反应 
式 的 方式 看 待 问题 ， 然 后 再 借助 这 一 令 人 兴奋 的 编程 范式 的 优秀 特性 构 
建 程序 。 


本 书包 含 了 一 些 使 用 RxJava 的 具体 样 例 ， 用 来 解决 Android 设 备 和 服务 器 
端的 实际 性 能 问题 。 你 将 会 学 到 RxJava 如 何 借助 并 行 和 并 发 解决 当前 的 
问题 。 本 书 还 特别 收录 了 2.0 版 本 的 基本 情况 。 


四 编写 对 多 个 异步 源 输入 进行 响应 的 程序 ， 避 免 陷 入 “回调 地 狱 ” 
加 理解 如 何以 反应 式 的 方式 解决 问题 

国 处 理 Observable 生 产 数 据 太 快 的 问题 

加 探索 调试 和 测试 反应 式 程序 的 策略 

加 在 程序 中 高 效 利 用 并 行 和 并 发 

加 学 习 如 何 迁 移 至 RxJava 2.0 版 本 


托 马 什 . 努 尔 凯 维 茨 (Tomasz Nurkiewicz) ， 软件 工程 师 ， 热 爱 JVM 语 


言 和 开源 技术 ， 经 常 为 DZone 网 站 撰写 博客 ， 并 在 世界 各 地 的 Java 会 
议 上 发 表演 讲 。 
本 克 里 斯 滕 森 (Ben Christensen) ， 软 件 工 程 师 ， 曾 在 苹果 、Netflix 和 


Facebook 公 司 工 作 ， 专 注 于 弹性 、 扩 展 性 和 分 布 式 系统 ， 为 Hystrix 和 
RxJava 等 开源 项 目 做 出 了 贡献 。 


“这 本 书 深入 探讨 了 RxJava 的 理 


念 和 用 法 ， 以 及 反应 式 编程 的 
通用 知识 。 两 位 作者 在 实现 和 
使 用 RxJava 方 面 拥 有 丰富 的 经 
验 。 如 果 你 想 掌 握 反 应 式 编程 ， 
那么 没有 比 阅读 这 本 书 更 好 的 
为 法 Te” 

一 一 Erik Meijer 
Applied Duality 公 司 总 裁 兼 创 始 人 


“对 于 现代 Android 应 用 程序 来 讲 ， 


高 度 状态 化 、 并 发 和 异步 实现 
是 基本 的 特性 ， 而 RxJava 是 管 
理 它们 的 好 工具 。 这 本 书 既 是 一 
个 渐进 式 的 学 习 工 具 ， 也 是 一 份 
随时 可 翻阅 的 参考 资料 ， 如 果 
没有 它 ， 掌 握 RxJava 这 个 库 可 
能 会 非常 困难 。” 
一 一 Jake Wharton 
Square 公司 软件 工程 师 
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